|
Nedávno se objevil MySQL server kvůli speciálním okolnostem“CHYBA 1129 (00000): Hostitel 'xxx' je blokován kvůli mnoha chybám připojení. Odblokujte pomocí 'mysqladmin flush-hosts'”Po vyřešení problému, při procesu poznávání parametru max_connect_errors, mě některé protichůdné popisy různých síťových dat trochu zmátly (u této chyby je podstatným důvodem, že stejná IP generovala příliš mnoho přerušených databázových spojení (překračujících maximální hodnotu max_connect_errors) v krátkém čase, a následuje proces zkoumání mých problémů, analýzy problémů a vyjasňování pochybností. Nejprve jsem hledal informace na internetu, z nichž mnohé slibují, že pokud počet pokusů o zadání hesla překročí max_connect_errors proměnné, MySQL toto přihlášení klienta zablokuje, a pak jsem našel oficiální informace o zavedení max_connect_errors, jak je uvedeno níže, MySQL 5.6/5.7 je stejný Pokud je více než tolik po sobě jdoucích požadavků na spojení z hostitele přerušeno bez úspěšného připojení, server zablokuje hostiteli další připojení. Blokované hostitele můžete odblokovat vyčištěním cache hostitele. K tomu vydat příkaz FLUSH HOSTS nebo spustit příkaz mysqladmin flush-hosts. Pokud je spojení úspěšně navázáno během méně než max_connect_errors pokusů po přerušení předchozího připojení, počet chyb hostitele se vymaže na nulu. Jakmile je hostitel zablokován, jediný způsob, jak ho odblokovat, je vyčištění cache hostitele. Výchozí hodnota je 100. Jak je uvedeno výše, překlad je přibližně následující: Pokud server MySQL obdrží po sobě jdoucí požadavky ze stejného hostitele a všechny tyto požadavky jsou přerušeny bez úspěšného navázání spojení, pokud je kumulativní hodnota těchto po sobě jdoucích požadavků větší než nastavená hodnota max_connect_errors, server MySQL zablokuje všechny následující požadavky z tohoto hostitele. Věřím, že když tyto informace uvidíte na začátku, budete také napadeni“Mnoho po sobě jdoucích požadavků na spojení z hostitele je přerušeno bez úspěšného připojení”Ve skutečnosti je to zmatené, protože připojení k databázi je přerušeno kvůli síťovým abnormalitám. Hledal jsem takové informace na internetu: Zdá se, že kolem této proměnné panuje zmatek. Neblokuje hostitele kvůli opakovaným neplatným heslům, ale spíše kvůli přerušeným spojením kvůli chybám v síti. Pak můžeme experimentovat a ověřit si to sami, abychom zjistili, která je správná. Vytvořte testovací účet v databázi MySQL a poté nastavíme proměnnou max_connect_errors na3. Poté použijeme další testovací stroj k připojení k databázi MySQL s nesprávným heslem, jak je uvedeno níže, i když jsou zadány předchozí tři špatná hesla, čtvrtý vstup nenarazí na výše uvedenou chybu.Pak můžete vyloučit, že tato proměnná souvisí se špatným zadaním hesla. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 1045 (28000): Přístup zamítnut uživateli 'test'@'mytestlnx02' (pomocí hesla: ANO) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 1045 (28000): Přístup zamítnut uživateli 'test'@'mytestlnx02' (pomocí hesla: ANO) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 1045 (28000): Přístup zamítnut uživateli 'test'@'mytestlnx02' (pomocí hesla: ANO) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 1045 (28000): Přístup zamítnut uživateli 'test'@'mytestlnx02' (pomocí hesla: ANO) [root@mytestlnx02 TMP] # Ve skutečnosti, pokud IP zadá nesprávné heslo, MySQL jej zaznamená do tabulky host_cache pod databází performance_schema. Je kumulativně zaznamenán v COUNT_AUTHENTICATION_ERRORS polích následovně:
Podle oficiálních informací je host_cache pole statisticky považováno za“Ucpání”chyb spojení (hodnocených na základě max_connect_errors systémových proměnných). Počítají se pouze chyby protokolového handshake a používají se pouze pro ověřené hostitele (HOST_VALIDATED = ANO). SUM_CONNECT_ERRORS Počet chyb spojení, které jsou považovány za "blokující" (hodnocené protimax_connect_errorssystémovou proměnnou). Počítají se pouze chyby protokolového handshake, a to pouze u hostitelů, kteří prošli validací (HOST_VALIDATED = ANO). MySQLKlient musí zahájit protokol trojnásobného handshake, aby navázal spojení s databází, za normálních okolností je tento čas velmi krátký, ale jakmile se objeví síťová anomálie, vypršení času a další faktory, způsobí to, že protokol handshake nebude dokončen. MySQL má parametr connect_timeout, je to čas, kdy MySQL server zpracuje mysqld na navázání připojení, a to během několika sekund. Pokud protokolový handshake není dokončen po uplynutí connect_timeout časového rámce, klient MySQL obdrží výjimku s výjimkou podobnou tomu: Ztratený kontakt s MySQL serverem na 'XXX', systémová chyba: errno, proměnná je výchozí na 10 sekund:
Představme si případ, kdy je připojení k databázi přerušeno kvůli časovému limitu sítě, použijeme příkazy netem a tc v Linuxu k simulaci zpoždění síťového přenosu v komplexním prostředí, po následujících nastaveních bude v tuto chvíli od testovacího serveru přístup k MySQL serveru zpoždění 11 sekund: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtů dat. 64 bajtů z 10.20.57.24: icmp_seq=1 TTL=62 Time=0,251 ms 64 bajtů z 10.20.57.24: icmp_seq=2 TTL=62 Time=0,330 ms 64 bajtů z 10.20.57.24: icmp_seq=3 ttl=62 čas=0,362 ms 64 bajtů z 10.20.57.24: icmp_seq=4 TTL=62 Time=0,316 ms 64 bajtů z 10.20.57.24: icmp_seq=5 ttl=62 čas=0,281 ms 64 bajtů z 10.20.57.24: icmp_seq=6 TTL=62 Time=0,377 ms ^C --- 10.20.57.24 ping statistiky --- 6 přenesených paketů, 6 přijatých, 0% ztráta paketů, čas 5716 ms RTT min/avg/max/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# tc qdisc přidat dev eth0 kořenový netem delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtů dat. 64 bajtů z 10.20.57.24: icmp_seq=1 ttl=62 čas=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=2 TTL=62 Time=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=3 TTL=62 Time=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=4 ttl=62 čas=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=5 TTL=62 Time=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=6 TTL=62 Time=11000 ms 64 bajtů z 10.20.57.24: icmp_seq=7 TTL=62 Čas=11000 ms
Připojujeme se k databázi MySQL na testovacím serveru gettestlnx02, jak je uvedeno níže (poznámka: pokud se k tomuto serveru připojujete přes SSH, bude v tuto chvíli provoz na gettestlx02 poměrně pomalý). Samozřejmě můžete také simulovat latenci sítě na MySQL serveru, nebo můžete snížit latenci connect_timeout i sítě) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 2013 (HY000): Ztratena spojení s MySQL serverem při 'čtení autorizačního paketu', systémová chyba: 0 [root@gettestlnx02 ~] # Jak je uvedeno výše, kvůli síťovému zpoždění přesahujícím 10 sekund selhalo připojení k MySQL, v tuto chvíli při dotazování tabulky host_cache na serveru MySQL uvidíte, že SUM_CONNECT_ERRORS se změnil na 1 a změnil se také COUNT_HANDSHAKE_ERRORS1.
Pak takto házíme třikrát opakovaně a uvidíte, že SUM_CONNECT_ERRORS se změní na 3 a COUNT_HANDSHAKE_ERRORS na 3. Poté použijeme příkazy netem a tc k zrušení simulace latence sítě na testovacím serveru a poté přejdeme na testovací spojení s MySQL databází, jak je ukázáno v následujícím testu: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Zadejte heslo: CHYBA 1129 (HY000): Hostitel '192.168.27.180' je blokován kvůli mnoha chybám připojení; Odblokujte pomocí 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
V tuto chvíli jej lze postavit“CHYBA 1129 (HY000): Hostitel '192.168.27.180' je blokován kvůli mnoha chybám připojení; Odblokujte pomocí 'mysqladmin flush-hosts'”Špatně. řešení Vyřešena CHYBA 1129 (00000): Hostitel 'xxx' je blokován kvůli mnoha chybám připojení. Existuje mnoho způsobů, jak získat chybu Unblock pomocí 'mysqladmin flush-hosts', ale některé jsou dočasné. Dočasný plán je, že indikátory neřeší hlavní příčinu. Klíčem je opravit síťové chyby (které často vyžadují konzultaci se správci sítě nebo systémovými administrátory) Řešení: 1, nastavte hodnotu proměnné max_connection_errors na větší hodnotu
Toto dočasné řešení je pouze podmínkou spouštějící zpoždění, která umožňuje IP zakázat, a v složitých případech nebo vysoké souběžnosti je nutné nastavit velkou hodnotu, jinak bude snadno znovu spuštěna. Navíc proměnné začínají platit pouze v aktuálním prostředí a vyprší, pokud jsou znovu spuštěny. 2: použitíFlush hostitelé mysql> flush hosts; Dotaz OK, 0 řádků ovlivněno (0,00 sekundy) mysql> vyberte * z performance_schema.host_cache; Prázdná sada (0,00 sekundy) mysql> Samozřejmě můžete také použít příkaz mysqladmin flush-hosts k vyčištění informací o cache hostů [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Zadejte heslo: Co je to hostitelská cache? Oficiální úvod je následující: MySQL server udržuje v paměti hostitelskou cache, která obsahuje informace o klientech: IP adresu, název hostitele a chybové informace. Server tuto cache používá pro nelokální TCP spojení. Nepoužívá cache pro TCP spojení navázaná pomocí adresy loopback rozhraní (127.0.0.1 nebo ::1), ani pro spojení navázaná pomocí unixového socket souboru, pojmenovaného pipe nebo sdíleného Paměť. Jednoduše řečeno, MySQL server udržuje cache v paměti obsahující informace o klientovi: IP adresu, název hostitele, chybovou zprávu atd. Server uchovává do mezipaměti informace o nelokálním TCP připojení. Neukládá do mezipaměti TCP spojení vytvořená pomocí adres rozhraní loopback (127.0.0.1 nebo::1), ani spojení vytvořená pomocí unixových socketových souborů, pojmenovaných pipeline nebo sdílené pamětě. Informace o cache hostitele lze dotazovat prostřednictvím tabulky host_cache v databázi performance_schema. 3: Nastavte proměnnou host_cache_size na0 Ve skutečnosti bych řekl, že je to nejnespolehlivější řešení, jen aby MySQL server nelogoval informace z cache hostitele. Tuto metodu lze zcela ignorovat.
| 
Zveřejněno 08.04.2019 11:01:48
|
|
|
|
