MySQL hiba a kommunikációs csomagok olvasásakor

A MySQL Connections egyik csendes gyilkosa a MySQL csomag.

Először derítsük ki, mi az a MySQL csomag.

A “MySQL belső használatának megértése” (ISBN 0-596-00957) 99. oldal szerint. -7) , itt vannak az 1-3. Bekezdések, amelyek a MySQL csomagokat magyarázzák:

A MySQL hálózati kommunikációs kódot abból a feltételezésből írtam, hogy a lekérdezések mindig ésszerűen rövid, és ezért egy kiszerelésben elküldhető és feldolgozható a szerver számára, amelyet a MySQL terminológiájában csomagnak hívnak. A kiszolgáló egy ideiglenes pufferhez rendeli a memóriát a csomag tárolásához, és annyit kér, hogy teljes egészében elférjen benne. Ez az architektúra elővigyázatosságot igényel annak elkerülése érdekében, hogy a kiszolgáló memóriája elfogyjon – a csomag méretének korlátozása, amit ez az opció megvalósít.

Az opcióval kapcsolatos érdekes kód a sql / net_serv.cc . Vessen egy pillantást a my_net_read () oldalra, majd kövesse a my_real_read hívást () és fordítson különös figyelmet a net_realloc () .

Ez a változó korlátozza számos string függvény eredményének hosszát is. Lásd: sql / field.cc és sql / intem_strfunc.cc a részletekért.

Ennek ismerete a MySQL-csomagokról lehetővé teszi, hogy a Fejlesztő / DBA méretbe állítsa őket, hogy több BLOB-ot is befogadhassanak. egy csomag belsejében, még akkor is, ha kellemetlenül nagyok. A túl kicsi csomag mindenképpen problémákat okoz ebben a tekintetben a nyitott kapcsolatok számára.

A szerint MySQL dokumentáció

• Ezeket a hibákat akkor is előfordulhatja, ha hibás vagy túl sok lekérdezést küld a szervernek nagy. Ha a mysqld túl nagy vagy rendezetlen csomagot kap, akkor feltételezi, hogy valami nem stimmel az ügyféllel, és lezárja a kapcsolatot. Ha nagy lekérdezésekre van szüksége (például, ha nagy BLOB oszlopokkal dolgozik), akkor növelheti a lekérdezési korlátot a kiszolgáló max_allowed_packet változójának beállításával, amelynek alapértelmezett értéke 1 MB. Lehetséges, hogy növelnie kell a maximális értéket is. csomagméret az ügyfél végén. További információ a csomagméret beállításáról a C.5.2.10. szakaszban található: „Túl nagy a csomag”.

• Az INSERT vagy a REPLACE utasítás, amely nagyon sok sort szúr be, szintén ilyen típusú hibákat okozhat. Ezen utasítások bármelyike egyetlen kérést küld a szervernek, a beillesztendő sorok számától függetlenül. ; így gyakran elkerülheti a hibát azáltal, hogy csökkenti az INSERT vagy a REPLACE küldött sorok számát.

AJÁNLÁS

Próbálja meg emelni a max_allowed_packet sokkal nagyobb számra, mivel az alapértelmezett érték 1 millió. Az ld körülbelül 10-szereset javasol az aktuális adatkészletben lévő legnagyobb TEXT vagy BLOB mezőben.

A max_allowed_packet 256M értékre állításához adhatja hozzá az /etc/my.cnf vagy my.ini fájlokhoz

[mysqld] max_allowed_packet=256M 

a mysqld jövőbeli újraindításainak fedezésére. Az érték most a szerverre történő telepítéséhez futtassa ezt:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Próbálja ki !!!

Megjegyzések

• Nagyon jó magyarázat.
• @RolandoMySQLDBA Még mindig hibaüzenetet kapok az 5.7.28-as verzióban, miután kipróbáltam az összes említett megoldást. Minden tipp a további hibaelhárításhoz

Alapértelmezés szerint a max_connections értéke 100 lesz. Próbálja meg növelni a / p>

max_connections = 400, miután a my.cnf fájlban beállította, indítsa újra a szervert, vagy állítsa be dinamikusan:

 set @@global.max_connections = 400; 

Csak próbálja meg a fenti ajánlást: kerülje ezeket a figyelmeztető üzeneteket, és ügyeljen arra is, hogy a hálózatán ne legyen csomagcsepp.

Nemrégiben találkoztam ezzel a problémával, miután elköltöztem A MySQL Enterprise 5.1.x -ről 5.7.x -re, az alkalmazás jelentős kódváltoztatása nélkül a „ note ” megjelent.

Esetemben a “ note ” megjelenésének kiváltó oka az volt, hogy a program kilépett a még nyitott kapcsolatokkal.Az a körülmény, hogy a kapcsolatok nincsenek lezárva, kicsit jobban érintettek voltak, és nem a MySQL-hez, hanem az ACE-hez, a szálakhoz és a TSS-hez kapcsolódtak.

Itt nem említik, ezért a probléma másik okát is felsorolom. Esetemben a mysql parancssori kliens használata közben a hibát interactive_timeout alacsony, 30 másodperces értéke okozta:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Ez továbbra is fennmarad a munkamenetek során, de a szerver nem indul újra.

SET GLOBAL interactive_timeout=6000; 

Ugyanazzal a problémával találkoztam a MariaDB 10.3.24-tel. Úgy tűnik, hogy a figyelmeztetés előfordulhat a fenti okok, majd néhány miatt. Esetemben az egyik adatbázis-táblázat rekordjának volt köszönhető, amelynek üres szótárértéke volt az egyik mezőnél.

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

Tesztként a “{}” értéket “()” -re változtattam, és ezzel leállítottam az üzenetet. Csak abban az esetben, ha valakinek segít.

Ez a my.ini sor megoldotta a problémámat:

log_error_verbosity=1 

Hivatkozás erre a linkre

Megjegyzések

• Nem hiszem, hogy ' nem gondoltam volna, hogy megoldotta az alapvető problémát, de egyszerűen leállította a naplózást.
• Ugyanazt az üzenetet jelentettem, mint egy " Megjegyzés ". A log_error_verbosity = 2 használata valójában megoldja a " problémát " (de egy " figyelmeztetés " címzéssel kell foglalkozni, nem szabad figyelmen kívül hagyni)