MySQL feil ved lesing av kommunikasjonspakker

En av de stille morderne på MySQL Connections er MySQL-pakken.

La oss først finne ut hva en MySQL-pakke er.

I henhold til side 99 i «Forstå MySQL internals» (ISBN 0-596-00957 -7) , her er avsnitt 1-3 som forklarer MySQL-pakker:

MySQL-nettverkskommunikasjonskoden ble skrevet under antagelse om at spørsmål alltid er rimelig kort, og kan derfor sendes til og behandles av serveren i en del, som kalles en pakke i MySQL-terminologi. Serveren tildeler minnet til en midlertidig buffer for å lagre pakken, og den ber om nok til å passe den helt. Denne arkitekturen krever en forholdsregel for å unngå at serveren går tom for minne — et tak på størrelsen på pakken, som dette alternativet oppnår.

Koden av interesse i forhold til dette alternativet finnes i sql / net_serv.cc . Ta en titt på my_net_read () , og følg deretter samtalen til my_real_read () og vær spesielt oppmerksom på net_realloc () .

Denne variabelen begrenser også lengden på et resultat av mange strengfunksjoner. Se sql / field.cc og sql / intem_strfunc.cc for detaljer.

Når du vet dette om MySQL-pakker, kan en utvikler / DBA tilpasse dem for å imøtekomme flere BLOB inne i en pakke selv om de er ubehagelig store. Definitivt vil en pakke for liten forårsake problemer for åpne forbindelser i denne forbindelse.

I følge MySQL-dokumentasjon

• Du kan også få disse feilene hvis du sender et spørsmål til serveren som er feil eller for stor. Hvis mysqld mottar en pakke som er for stor eller ute av drift, antar den at noe har gått galt med klienten og lukker forbindelsen. Hvis du trenger store spørsmål (for eksempel hvis du jobber med store BLOB-kolonner), kan du øke søkegrensen ved å angi serverens «max_allowed_packet variabel, som har en standardverdi på 1 MB. Du må kanskje også øke maksimum pakkestørrelse på klientsiden. Mer informasjon om innstilling av pakkestørrelse er gitt i Seksjon C.5.2.10, «Pakke for stor».

• En INSERT- eller REPLACE-setning som setter inn mange rader, kan også forårsake slike feil. Enten av disse utsagnene sender en enkelt forespørsel til serveren uavhengig av antall rader som skal settes inn ; dermed kan du ofte unngå feilen ved å redusere antall sendte rader per INSERT eller ERSTAT.

ANBEFALING

Prøv å heve max_allowed_packet til et mye større tall, siden standard er 1M. Jeg vil Jeg foreslår omtrent ti ganger det største TEXT- eller BLOB-feltet du har i ditt nåværende datasett.

Hvis du vil sette max_allowed_packet til 256M, kan du legge det til /etc/my.cnf eller my.ini

[mysqld] max_allowed_packet=256M 

for å dekke fremtidige omstart av mysqld. For å installere verdien nå på serveren, vennligst kjør denne:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Prøv det !!!

Kommentarer

• Veldig god forklaring.
• @RolandoMySQLDBA Jeg får fortsatt feil i 5.7.28 etter å ha prøvd alle nevnte løsninger. Eventuelle tips for ytterligere feilsøking

Som standard vil max_connections være 100. Prøv å øke konfigurasjonsparameteren

max_connections = 400, etter innstilling i my.cnf, start serveren på nytt, eller sett den dynamisk:

 set @@global.max_connections = 400; 

Bare prøv ovennevnte anbefaling til unngå disse advarselsmeldingene, og sørg også for at nettverket ditt ikke har noen pakkedråper.

Jeg har nylig opplevd dette problemet etter å ha flyttet fra MySQL Enterprise 5.1.x til 5.7.x , uten noen signifikante kodeendringer i applikasjonen, begynte « note » å vises.

I mitt tilfelle var årsaken til « notat » som dukket opp, programmet som avsluttes med tilkoblinger fortsatt åpne.Omstendigheten for at forbindelser ikke ble stengt var litt mer involvert og ikke relatert til MySQL men ACE, tråder og TSS.

Ikke nevnt her, så jeg inkluderer en annen årsak til dette problemet. I mitt tilfelle ble feilen forårsaket av en lav verdi på 30 sekunder på interactive_timeout mens jeg brukte mysql kommandolinjeklienten:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Dette vil vedvare på tvers av øktene, men ikke en serverstart på nytt.

SET GLOBAL interactive_timeout=6000; 

Jeg kom over det samme problemet med MariaDB 10.3.24. Virker som advarselen kan oppstå av alle de ovennevnte årsakene og deretter noen. I mitt tilfelle skyldtes det en registrering i en av databasetabellene som hadde en tom ordbokverdi for et av feltene.

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

Som test endret jeg «{}» til «()» og det stoppet meldingen. Bare i tilfelle det hjelper noen.

Denne my.ini-linjen løste problemet mitt:

log_error_verbosity=1 

Referanse denne lenken

Kommentarer

• Jeg tror ikke ' jeg tror ikke du har løst det underliggende problemet, men rett og slett stoppet at det ble logget.
• Jeg fikk den samme meldingen rapportert som en " Merk ". Bruk av log_error_verbosity = 2 løser faktisk " problemet " (men en " Advarsel " bør adresseres, ikke ignoreres)