MySQL-fel vid läsning av kommunikationspaket

En av de tysta mördarna i MySQL-anslutningar är MySQL-paketet.

Låt oss först ta reda på vad ett MySQL-paket är.

Enligt sidan 99 i ”Förstå MySQL Internals” (ISBN 0-596-00957 -7) , här är punkterna 1-3 som förklarar MySQL-paket:

MySQL-nätverkskommunikationskoden skrevs under antagandet att frågor alltid är rimligt kort och kan därför skickas till och bearbetas av servern i en bit, som kallas ett paket i MySQL-terminologi. Servern tilldelar minnet för en tillfällig buffert för att lagra paketet, och den begär tillräckligt för att passa helt. Denna arkitektur kräver en försiktighetsåtgärd för att undvika att servern tar slut på minne — ett tak på storleken på paketet, vilket detta alternativ åstadkommer.

Intressekoden i förhållande till detta alternativ finns i sql / net_serv.cc . Ta en titt på my_net_read () , följ sedan samtalet till my_real_read () och ägna särskild uppmärksamhet åt net_realloc () .

Denna variabel begränsar också längden på ett resultat av många strängfunktioner. Se sql / field.cc och sql / intem_strfunc.cc för detaljer.

Att veta detta om MySQL-paket gör det möjligt för en utvecklare / DBA att dimensionera dem för att rymma flera BLOB inuti ett paket även om de är motbjudande stora. Definitivt kommer ett paket för litet att orsaka problem för öppna anslutningar i detta avseende.

Enligt MySQL-dokumentation

• Du kan också få dessa fel om du skickar en fråga till servern som är felaktig eller för stor. Om mysqld får ett paket som är för stort eller inte i ordning, antar det att något har gått fel med klienten och stänger anslutningen. Om du behöver stora frågor (till exempel om du arbetar med stora BLOB-kolumner) kan du öka frågegränsen genom att ställa in servern s variabel max_allowed_packet, som har ett standardvärde på 1 MB. Du kan också behöva öka paketstorlek i klientänden. Mer information om hur du ställer in paketstorleken finns i Avsnitt C.5.2.10, ”Paket för stort”.

• Ett INSERT- eller REPLACE-uttalande som infogar många rader kan också orsaka sådana fel. Endera av dessa uttalanden skickar en enskild begäran till servern oavsett antalet rader som ska infogas ; Därför kan du ofta undvika felet genom att minska antalet rader som skickas per INSÄTTNING eller ERSÄTT.

REKOMMENDATION

Försök att höja max_allowed_packet till ett mycket större antal, eftersom standardvärdet är 1 M. Jag vill Jag föreslår ungefär tio gånger det största TEXT- eller BLOB-fältet du har i din nuvarande dataset.

Om du vill ställa in max_allowed_packet till 256M kan du lägga till det i /etc/my.cnf eller my.ini

[mysqld] max_allowed_packet=256M 

för att täcka framtida omstart av mysqld. För att installera värdet nu på servern, kör det här:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Testa det !!!

Kommentarer

• Mycket bra förklaring.
• @RolandoMySQLDBA Jag får fortfarande fel i 5.7.28 efter att ha provat alla nämnda lösningar. Eventuella tips för ytterligare felsökning

För det mesta är max_connections som standard 100. Försök att öka konfigurationsparametern

max_connections = 400, efter inställning i my.cnf startar om servern eller ställer in den dynamiskt:

 set @@global.max_connections = 400; 

Försök bara ovanstående rekommendation till undvik dessa varningsmeddelanden och se till att ditt nätverk inte har några paketfall.

Jag stötte på det här problemet nyligen efter att jag flyttat från MySQL Enterprise 5.1.x till 5.7.x , utan några betydande kodändringar i applikationen började ” not ” att visas.

I mitt fall var grundorsaken till ” anteckningen ” det program som avslutades med anslutningar fortfarande öppna.Omständigheterna för att anslutningar inte stängdes var lite mer involverade och inte relaterade till MySQL utan ACE, trådar och TSS.

Inte nämnt här så jag tar med en annan orsak till problemet. I mitt fall orsakades felet av ett lågt värde på 30 sekunder av interactive_timeout när jag använde mysql-kommandoradsklienten:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Detta kommer att kvarstå över sessioner men inte omstart av en server.

SET GLOBAL interactive_timeout=6000; 

Jag stötte på samma problem med MariaDB 10.3.24. Verkar som att varningen kan uppstå av alla ovanstående skäl och sedan några. I mitt fall berodde det på en post i en av databastabellerna som hade ett tomt ordboksvärde för ett av fälten.

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

Som ett test ändrade jag ”{}” till ”()” och det stoppade meddelandet. Om det hjälper någon.

Denna my.ini-rad löste mitt problem:

log_error_verbosity=1 

Referens den här länken

Kommentarer

• Jag tror inte ' att du inte har löst det bakomliggande problemet men helt enkelt har stoppat att det loggas.
• Jag fick samma meddelande rapporterat som ett " Obs ". Användning av log_error_verbosity = 2 löser faktiskt " problemet " (men en " Varning " bör adresseras, inte ignoreras)