MySQL-fout bij het lezen van communicatiepakketten

Een van de stille moordenaars van MySQL Connections is het MySQL-pakket.

Laten we eerst eens kijken wat een MySQL-pakket is.

Volgens de pagina 99 van “Understanding MySQL Internals” (ISBN 0-596-00957 -7) , hier zijn paragrafen 1-3 die MySQL-pakketten uitleggen:

MySQL-netwerkcommunicatiecode is geschreven in de veronderstelling dat zoekopdrachten altijd redelijk kort, en kan daarom in één stuk naar de server worden verzonden en daar door de server worden verwerkt, dat in MySQL-terminologie een pakket wordt genoemd. De server wijst het geheugen toe voor een tijdelijke buffer om het pakket op te slaan, en het vraagt genoeg om het volledig te passen. Deze architectuur vereist een voorzorgsmaatregel om te voorkomen dat de server onvoldoende geheugen heeft — een limiet op de grootte van het pakket, wat deze optie bereikt.

De code van belang met betrekking tot deze optie is te vinden in sql / net_serv.cc . Bekijk my_net_read () en volg de oproep naar my_real_read () en let vooral op net_realloc () .

Deze variabele beperkt ook de lengte van een resultaat van veel tekenreeksfuncties. Zie sql / field.cc en sql / intem_strfunc.cc voor details.

Als je dit weet over MySQL-pakketten, kan een ontwikkelaar / DBA ze aanpassen aan meerdere BLOBs in één pakket, zelfs als ze onaangenaam groot zijn. Een te klein pakket zal in dit opzicht zeker problemen veroorzaken voor open verbindingen.

Volgens de MySQL-documentatie

• U kunt deze fouten ook krijgen als u een zoekopdracht naar de server verzendt die onjuist of te groot. Als mysqld een pakket ontvangt dat te groot of niet in orde is, gaat het ervan uit dat er iets mis is gegaan met de client en wordt de verbinding verbroken. Als u grote zoekopdrachten nodig heeft (als u bijvoorbeeld met grote BLOB-kolommen werkt), kunt u de querylimiet verhogen door de variabele max_allowed_packet van de server in te stellen, die een standaardwaarde van 1 MB heeft. Mogelijk moet u ook het maximum verhogen pakketgrootte aan de clientzijde. Meer informatie over het instellen van de pakketgrootte wordt gegeven in Paragraaf C.5.2.10, “Pakket te groot”.

• Een INSERT- of REPLACE-instructie die een groot aantal rijen invoegt, kan ook dit soort fouten veroorzaken. Elk van deze instructies stuurt een enkel verzoek naar de server, ongeacht het aantal rijen dat moet worden ingevoegd ; daarom kunt u de fout vaak voorkomen door het aantal rijen dat wordt verzonden per INSERT of REPLACE te verminderen.

AANBEVELING

Probeer de max_allowed_packet naar een veel groter getal, aangezien de standaardwaarde 1M is. Ik wil ld suggereert ongeveer 10 keer het grootste TEXT- of BLOB-veld dat je in je huidige dataset hebt.

Om het max_allowed_packet in te stellen op 256M, kun je het toevoegen aan /etc/my.cnf of my.ini

[mysqld] max_allowed_packet=256M 

om toekomstige herstarts van mysqld te dekken. Voer dit uit om de waarde nu op de server te installeren:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Probeer het eens !!!

Opmerkingen

• Zeer goede uitleg.
• @RolandoMySQLDBA Ik krijg nog steeds een foutmelding in 5.7.28 nadat ik alle genoemde oplossingen heb geprobeerd. Alle tips om problemen verder op te lossen

Meestal is max_connections 100. Verhoog de configuratieparameter

max_connections = 400, na het instellen in my.cnf herstart de server, of stel deze dynamisch in:

 set @@global.max_connections = 400; 

Probeer gewoon de bovenstaande aanbeveling om vermijd deze waarschuwingsberichten en zorg er ook voor dat uw netwerk geen pakketuitval heeft.

Ik kwam dit probleem onlangs tegen nadat ik was verhuisd van MySQL Enterprise 5.1.x tot 5.7.x , zonder enige significante codewijzigingen aan de applicatie begon de “ note ” te verschijnen.

In mijn geval was de hoofdoorzaak voor het verschijnen van de “ note ” het programma dat werd afgesloten met nog open verbindingen.De omstandigheid dat verbindingen niet werden gesloten, waren iets meer betrokken en hadden geen betrekking op MySQL maar ACE, threads en TSS.

Hier niet vermeld, dus ik neem een andere oorzaak van dit probleem op. In mijn geval werd de fout bij het gebruik van de mysql-opdrachtregelclient veroorzaakt door een lage waarde van 30 seconden van interactive_timeout:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Dit blijft gedurende sessies bestaan, maar de server wordt niet opnieuw opgestart.

SET GLOBAL interactive_timeout=6000; 

Ik kwam hetzelfde probleem tegen met MariaDB 10.3.24. Het lijkt erop dat de waarschuwing kan optreden om alle bovenstaande redenen en nog enkele. In mijn geval was het te wijten aan een record in een van de databasetabellen met een lege woordenboekwaarde voor een van de velden.

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

Als test veranderde ik de “{}” in “()” en dat stopte het bericht. Voor het geval het iemand helpt.

Deze my.ini-regel loste mijn probleem op:

log_error_verbosity=1 

Verwijs naar deze link

Reacties

• Ik denk niet dat ' niet dat je het onderliggende probleem hebt opgelost, maar gewoon bent gestopt met het loggen.
• Ik kreeg hetzelfde bericht gerapporteerd als een " Opmerking ". Het gebruik van log_error_verbosity = 2 lost eigenlijk het " probleem " op (maar een " Waarschuwing " moet worden geadresseerd, niet genegeerd)