MySQL-fejl ved læsning af kommunikationspakker

En af de tavse drabere af MySQL-forbindelser er MySQL-pakken.

Lad os først finde ud af, hvad en MySQL-pakke er.

I henhold til side 99 i “Forstå MySQL Internals” (ISBN 0-596-00957 -7) , her er afsnit 1-3, der forklarer MySQL-pakker:

MySQL-netværkskommunikationskoden blev skrevet under den antagelse, at forespørgsler altid er rimelig kort og kan derfor sendes til og behandles af serveren i et stykke, der kaldes en pakke i MySQL-terminologi. Serveren tildeler hukommelsen til en midlertidig buffer til lagring af pakken, og den beder om nok til at passe den helt. Denne arkitektur kræver en forholdsregel for at undgå, at serveren løber tør for hukommelse — et loft på størrelsen på pakken, som denne mulighed udfører.

Koden af interesse i forhold til denne mulighed findes i sql / net_serv.cc . Se på my_net_read () , og følg derefter opkaldet til my_real_read () og vær særlig opmærksom på net_realloc () .

Denne variabel begrænser også længden af et resultat af mange strengfunktioner. Se sql / field.cc og sql / intem_strfunc.cc for detaljer.

At vide dette om MySQL-pakker gør det muligt for en udvikler / DBA at dimensionere dem til at rumme flere BLOBer inde i en pakke, selvom de er ubehageligt store. Definitivt vil en pakke for lille skabe problemer for åbne forbindelser i denne henseende.

Ifølge MySQL-dokumentation

• Du kan også få disse fejl, hvis du sender en forespørgsel til serveren, der er forkert eller for stor. Hvis mysqld modtager en pakke, der er for stor eller ikke i orden, antager den, at noget er gået galt med klienten og lukker forbindelsen. Hvis du har brug for store forespørgsler (f.eks. Hvis du arbejder med store BLOB-kolonner), kan du øge forespørgselsgrænsen ved at indstille serverens “max_allowed_packet-variabel, som har en standardværdi på 1 MB. Det kan også være nødvendigt at øge det maksimale antal pakkestørrelse i klientenden. Flere oplysninger om indstilling af pakkestørrelse findes i Afsnit C.5.2.10, “Pakke for stor”.

• En INSERT- eller REPLACE-sætning, der indsætter mange rækker, kan også forårsage denne slags fejl. Enten af disse udsagn sender en enkelt anmodning til serveren uanset antallet af rækker, der skal indsættes ; således kan du ofte undgå fejlen ved at reducere antallet af rækker, der sendes pr. INDSÆT eller ERSTAT.

ANBEFALING

Prøv at hæve max_allowed_packet til et meget større antal, da standard er 1M. Jeg ville Jeg foreslår cirka 10 gange det største TEXT- eller BLOB-felt, du har i dit nuværende datasæt.

For at indstille max_allowed_packet til 256M kan du tilføje det til /etc/my.cnf eller my.ini

[mysqld] max_allowed_packet=256M 

for at dække fremtidige genstart af mysqld. For at installere værdien nu på serveren skal du køre denne:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Prøv det !!!

Kommentarer

• Meget god forklaring.
• @RolandoMySQLDBA Jeg får stadig fejl i 5.7.28 efter at have prøvet alle de nævnte løsninger. Eventuelle tip til yderligere fejlfinding

Normalt er max_connections som standard 100. Prøv at øge konfigurationsparameteren

max_connections = 400, efter at have indstillet i my.cnf, genstart serveren eller indstil den dynamisk:

 set @@global.max_connections = 400; 

Prøv ovenstående anbefaling til undgå disse advarselsmeddelelser, og sørg også for, at dit netværk ikke har nogen pakkefald.

Jeg stødte på dette problem for nylig efter at have flyttet fra MySQL Enterprise 5.1.x til 5.7.x uden nogen vigtige kodeændringer i applikationen begyndte “ note ” at vises.

I mit tilfælde var grundårsagen til “ note “, der var programmet, der afsluttes med forbindelser stadig åbne.Omstændighederne for ikke at lukke forbindelser var lidt mere involverede og ikke relateret til MySQL men ACE, tråde og TSS.

Ikke nævnt her, så jeg inkluderer en anden årsag til dette problem. I mit tilfælde blev fejlen forårsaget af en lav værdi på 30 sekunder af interactive_timeout, mens jeg brugte mysql kommandolinjeklienten:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Dette fortsætter på tværs af sessioner, men ikke en servergenstart.

SET GLOBAL interactive_timeout=6000; 

Jeg stødte på det samme problem med MariaDB 10.3.24. Det ser ud til, at advarslen kan forekomme af alle ovenstående grunde og derefter nogle. I mit tilfælde skyldtes det en registrering i en af databasetabellerne, der havde en tom ordbogværdi for et af felterne.

+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +

Som test ændrede jeg “{}” til “()”, og det stoppede beskeden. Bare hvis det hjælper nogen.

Denne my.ini-linje løste mit problem:

log_error_verbosity=1 

Reference dette link

Kommentarer

• Jeg tror ikke ' Jeg tror ikke, du har løst det underliggende problem, men har simpelthen stoppet med at blive logget.
• Jeg fik den samme besked rapporteret som " Bemærk ". Brug af log_error_verbosity = 2 løser faktisk " problemet " (men en " Advarsel " skal adresseres, ikke ignoreres)