sql >> Databáze >  >> RDS >> Mysql

Běžná chyba MySQL:„Došlo k chybě při čtení komunikačního paketu“

MySQL je podle webu DB Engine druhou slavnou databází na světě za Oraclem. To, co dělá MySQL slavným, je pravděpodobně proto, že se jedná o velmi rychlý, spolehlivý a flexibilní systém správy databází. MySQL je také jednou z podporovaných databází v ClusterControl. S ClusterControl můžete snadno nasadit, škálovat, monitorovat a dělat spoustu věcí.

Dnes nebudeme hovořit o žádném z nich, ale probereme jednu z běžných chyb MySQL a možné tipy pro odstraňování problémů. Při práci s tikety, hodně času, když kontrolujeme chybová hlášení nebo protokoly, jsme poměrně často viděli tento řádek  „Chyba při čtení komunikačního paketu“. Myslíme si, že by bylo přínosné, kdybychom nejen pro naše zákazníky, ale i pro ostatní čtenáře napsali blog související s touto chybou. Nečekejme dál, je čas se více ponořit!

Protokol MySQL Client/Server

Nejprve musíme porozumět způsobu, jakým MySQL komunikuje mezi klientem a serverem. Klient i server využívají protokol MySQL, který je implementován pomocí konektorů, MySQL Proxy a také komunikace mezi master a slave replikačními servery. Protokol MySQL podporuje funkce jako transparentní šifrování přes SSL, transparentní kompresi, fázi připojení a také fázi příkazů.

Jak celá čísla, tak řetězce jsou základní datové typy, které se používají v celém protokolu MySQL. Kdykoli spolu klient a server MySQL chtějí komunikovat nebo posílat data, rozdělí data do paketů o maximální velikosti 16 MB a také ke každému bloku přidá hlavičku paketu. Uvnitř každého paketu bude užitečné zatížení, kde hrají svou roli datové typy (celá čísla/řetězce).

Vzhledem k tomu, že CLIENT_PROTOCOL_41 je povolen, na téměř každý příkaz, který klient odešle na server, server odpoví na kterýkoli z následujících paketů jako odpověď:

OK_Packet

Toto je signál pro každý úspěšný příkaz.

ERR_Packet

Signál indikuje chybu paketu.

EOF_Packet

Tento paket obsahuje varování nebo stavový příznak.

Jak diagnostikovat problémy

Obvykle existují dva typy problémů s připojením, kterými jsou komunikační chyby nebo přerušená připojení. Kdykoli dojde k některému z těchto problémů s připojením, následující zdroje informací jsou dobrým výchozím bodem pro řešení problémů a analýzu:

  • Protokol chyb

  • Obecný protokol dotazů

  • Stavové proměnné Aborted_xxx a Connection_errors_xxx

  • Hostitelská mezipaměť

Chyby připojení a možné důvody

V případě jakýchkoli chyb připojení a v závislosti na chybách zvýší stavový čítač pro Aborted_clients nebo Aborted_connects ve stavových proměnných. Jak je převzato z dokumentace MySQL, Aborted_clients znamená počet připojení, která byla přerušena, protože klient zemřel, aniž by připojení řádně uzavřel. Pokud jde o Aborted_connects, znamená to počet neúspěšných pokusů o připojení k serveru MySQL.

Pokud spustíte server MySQL s volbou --log-warnings, je pravděpodobné, že v protokolu chyb pravděpodobně uvidíte příklad následující zprávy. Jak jste si všimli, ve zprávě bylo jasně uvedeno, že se týká přerušení připojení, takže stavový čítač Aborted_connects bude zvýšen ve stavové proměnné:

[Varování] Přerušeno připojení 154669 k db:'wordpress' uživatel:'wpuser' hostitel:'hostname' (Při čtení komunikačních paketů došlo k chybě)

Za normálních okolností může dojít k neúspěšným pokusům o připojení z následujících důvodů. Když si toho všimnete, možná to naznačuje, že se neoprávněná osoba chystá narušit databázi a možná byste se na to chtěli co nejdříve podívat:

  • Klient nemá žádná oprávnění pro přístup k databázi.

  • Bylo použito nesprávné pověření.

  • Spojovací paket, který obsahuje nesprávné informace.

  • Vzhledem k dosažení limitu connect_timeout pro připojení.

Proměnná stavu pro Aborted_clients bude serverem zvýšena, pokud se klientovi podaří připojit, ale dojde k odpojení nebo ukončení nesprávným způsobem. Kromě toho server také zaznamená do protokolu chyb zprávu o přerušeném připojení. Tento typ chyby může být obvykle způsoben následujícím důvodem:

  • Klient před ukončením správně neuzavře připojení (nevolá mysql_close ()).

  • Klient překročil počet sekund wait_timeout nebo interactive_timeout.

  • Klientský program nebo aplikace náhle skončily uprostřed přenosu dat.

Kromě výše uvedených důvodů mohou další pravděpodobné důvody přerušení připojení a problémů s přerušenými klienty souviset s kterýmkoli z následujících:

  • Konfigurace TCP/IP selhala.

  • Hodnota proměnné je pro max_allowed_packet příliš malá.

  • Nedostatečné přidělení paměti pro dotazy.

  • Vadný hardware, jako jsou ethernety, přepínače, kabely atd.

  • Problémy s knihovnou vláken.

  • Problém s duplexním syndromem, kdy přenos probíhá v režimu burst-pause-burst-pause (pokud používáte ethernetový protokol s Linuxem, polovičním i plným duplexem).

Jak opravit chyby komunikace MySQL

Teď, když jsme se dozvěděli spoustu možností, které způsobovaly chyby připojení k MySQL. Na základě našich zkušeností se tento problém většinou týká firewallu nebo problémů se sítí. Je také spravedlivé říci, že není snadné diagnostikovat tento druh problému. Při řešení této chyby vám nicméně může pomoci následující řešení:

  • Pokud vaše aplikace spoléhá na ukončení spojení wait_timeout, vyplatí se změnit logiku aplikace tak, aby byla na konci jakékoli operace řádně uzavřena.

  • Ujistěte se, že hodnota pro max_allowed_packet je v přijatelném rozsahu, aby klient neobdržel žádnou chybu související s „Paket je příliš velký“.

  • Pro problémy se zpožděním připojení, které by mohly být způsobeny DNS, stojí za to zkontrolovat, zda nemáte skip-name- rozlišení povoleno.

  • Pokud používáte aplikaci PHP nebo jiné programování, nejlepší je zajistit, aby nedošlo k přerušení připojení, která jsou obvykle nastavena na max_execution_time.

  • Pokud jste si všimli mnoha TIME_WAIT oznámení z netstat, stojí za to potvrdit, že připojení jsou na konec aplikace.

  • Pokud používáte Linux a máte podezření, že problém je způsoben sítí, je nejlepší zkontrolovat síťové rozhraní pomocí příkazu ifconfig-a a zkontrolujte výstup na serveru MySQL, zda neobsahuje nějakou chybu.

  • Pro uživatele ClusterControl můžete povolit Audit Log z Cluster -> Security -> Audit Log. Povolením této funkce vám může pomoci zúžit hledání toho, který dotaz je viníkem.

  • Síťové nástroje jako tcpdump a Wireshark by mohly být užitečné při identifikaci potenciálních problémů se sítí, časových limitů a problémů se zdroji pro MySQL.

  • Pravidelně kontrolujte hardware a ujistěte se, že nejsou žádná vadná zařízení, zejména pokud jde o ethernety, rozbočovače, přepínače, kabely atd. Vyplatí se vyměnit vadný spotřebič, abyste se ujistili, že připojení je vždy dobré.

Závěr

Existuje mnoho důvodů, které by mohly vést k problémům s pakety připojení k MySQL. Kdykoli k tomuto problému dojde, určitě to ovlivní podnikání a každodenní provoz. I když tento typ problému není snadné diagnostikovat a většinou je to způsobeno sítí nebo firewallem, stojí za to vzít v úvahu všechny kroky, které byly dříve navrženy, aby se problém vyřešil. Opravdu doufáme, že vám tento blogový příspěvek může nějakým způsobem pomoci, zvláště když čelíte tomuto problému.


  1. Jak aktualizovat pomocí vnitřního spojení v Oracle

  2. Jak zaokrouhlovat čísla v SQL

  3. Jak chránit databázi MySQL nebo MariaDB před SQL Injection:Část druhá

  4. Je možné zřetězit hodnoty sloupců do řetězce pomocí CTE?