Chyba při čtení komunikačních paketů MySQL

Jedním z tichých zabijáků připojení MySQL je balíček MySQL.

Nejprve zjistíme, co je MySQL paket.

Podle stránky 99 „Pochopení interních funkcí MySQL“ (ISBN 0-596-00957 -7) , zde jsou odstavce 1–3 vysvětlující pakety MySQL:

Síťový komunikační kód MySQL byl napsán za předpokladu, že dotazy jsou vždy přiměřeně krátký, a proto jej lze odeslat a zpracovat serverem v jednom bloku, který se v terminologii MySQL nazývá paket . Server přiděluje paměť pro dočasnou vyrovnávací paměť pro uložení paketu a požaduje dost na to, aby se vešel úplně. Tato architektura vyžaduje preventivní opatření, aby se zabránilo vyčerpání paměti serveru — omezení velikosti paketu, čehož tato možnost dosahuje.

Kód zájmu týkající se této možnosti se nachází v sql / net_serv.cc . Podívejte se na my_net_read () a poté zavolejte na my_real_read () a věnujte zvláštní pozornost net_realloc () .

Tato proměnná také omezuje délku výsledku mnoha řetězcových funkcí. Viz sql / field.cc a sql / intem_strfunc.cc podrobnosti.

Znalost těchto MySQL paketů umožňuje vývojářům / DBA přizpůsobit je tak, aby vyhovovaly více BLOBům uvnitř jednoho balíčku, i když jsou nepříjemně velké. Příliš malý paket v tomto ohledu rozhodně způsobí problémy otevřeným připojením.

Podle Dokumentace MySQL

• Tyto chyby můžete také získat, pokud na server odešlete nesprávný dotaz nebo příliš velký. Pokud mysqld přijme paket, který je příliš velký nebo nefunkční, předpokládá, že se klientovi něco pokazilo, a zavře spojení. Pokud potřebujete velké dotazy (například pokud pracujete s velkými sloupci BLOB), můžete zvýšit limit dotazu nastavením proměnné max_allowed_packet serveru, která má výchozí hodnotu 1 MB. Možná budete muset také zvýšit maximální velikost paketu na straně klienta. Další informace o nastavení velikosti paketu jsou uvedeny v části C.5.2.10, „Příliš velký balíček“.

• Příkaz INSERT nebo REPLACE, který vloží velké množství řádků, může také způsobit tyto druhy chyb. Buď jeden z těchto příkazů odešle jeden požadavek na server bez ohledu na počet řádků, které mají být vloženy ; této chybě se tedy můžete často vyhnout snížením počtu řádků odeslaných na INSERT nebo REPLACE.

DOPORUČENÍ

Zkuste zvýšit max_allowed_packet na mnohem větší počet, protože výchozí hodnota je 1M. Navrhuji asi 10krát největší pole TEXT nebo BLOB ve vaší aktuální datové sadě.

Chcete-li nastavit max_allowed_packet na 256 M, můžete jej přidat do /etc/my.cnf nebo my.ini

[mysqld] max_allowed_packet=256M 

k pokrytí budoucích restartů mysqld. Chcete-li nyní nainstalovat hodnotu na server, spusťte toto:

SET GLOBAL max_allowed_packet = 1024 * 1024 * 256; 

Zkuste to !!!

Komentáře

• Velmi dobré vysvětlení.
• @RolandoMySQLDBA Po vyzkoušení všech zmíněných řešení se v 5.7.28 stále zobrazuje chyba. Jakékoli tipy k dalšímu řešení problémů

Ve výchozím nastavení bude max_connections 100. Zkuste zvýšit konfigurační parametr

max_connections = 400, po nastavení v my.cnf restartujte server nebo jej nastavte dynamicky:

 set @@global.max_connections = 400; 

Zkuste výše uvedené doporučení vyhněte se těmto varovným zprávám a také zajistěte, aby vaše síť neobsahovala žádné pakety.

S tímto problémem jsem se setkal nedávno po přesunu z MySQL Enterprise 5.1.x až 5.7.x , bez výrazných změn kódu aplikace se začala objevovat „ nota “.

V mém případě byla hlavní příčinou zobrazování „ poznámky “ program, který ukončil připojení stále otevřená.Okolnosti pro neuzavřená připojení byla trochu více zapojena a nesouvisela s MySQL, ale s ACE, podprocesy a TSS.

Není zde uvedeno, proto zahrnuji další příčinu tohoto problému. V mém případě při používání klienta příkazového řádku mysql byla chyba způsobena nízkou hodnotou 30 sekund interactive_timeout:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
To bude přetrvávat napříč relacemi, ale ne restart serveru.

SET GLOBAL interactive_timeout=6000; 

Na stejný problém jsem narazil s MariaDB 10.3.24. Zdá se, že varování může nastat ze všech výše uvedených důvodů a poté z některých. V mém případě to bylo kvůli záznamu v jedné z databázových tabulek, která měla pro jedno z polí prázdnou hodnotu slovníku.

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

Jako test jsem změnil „{}“ na „()“ a zpráva byla zastavena. Jen pro případ, že to někomu pomůže.

Tento řádek my.ini vyřešil můj problém:

log_error_verbosity=1 

Odkaz tento odkaz

Komentáře

• Nemyslím si ', že jste vyřešili základní problém, ale jednoduše jste jej zastavili v protokolování.
• Zobrazovala se mi stejná zpráva jako " Poznámka ". Použití log_error_verbosity = 2 skutečně řeší " problém " (ale " varování " by měl být adresován, ne ignorován)