|
Nedávno sa objavil MySQL server kvôli špeciálnym faktorom“CHYBA 1129 (00000): Hostiteľ 'xxx' je zablokovaný kvôli mnohým chybám spojenia. Odblokujte pomocou 'mysqladmin flush-hosts'”Keď bol problém vyriešený, počas procesu učenia sa viac o parametre max_connect_errors, ma niektoré protichodné opisy rôznych sieťových dát trochu zmiatli (pri tejto chybe je podstatným dôvodom to, že tá istá IP vygenerovala príliš veľa prerušených databázových spojení (prekračujúcich maximálnu hodnotu max_connect_errors) v krátkom čase, a nasleduje proces skúmania mojich problémov, analýzy problémov a vyjasňovania pochybností. Najprv som hľadal informácie na internete, z ktorých mnohé sľubujú, že ak počet pokusov o zadanie hesla presiahne max_connect_errors premenných, MySQL zablokuje toto prihlasovanie klienta, a potom som našiel oficiálne informácie o zavedení max_connect_errors, ako je uvedené nižšie, MySQL 5.6/5.7 je rovnaký Ak je prerušených viac po sebe idúcich požiadaviek na spojenie z hostiteľa bez úspešného spojenia, server zablokuje tento hostiteľ pred ďalšími spojeniami. Blokované hostiteľy môžete odblokovať vyčistením cache hostiteľa. Na to vydajte príkaz FLUSH HOSTS alebo spustite príkaz mysqladmin flush-hosts. Ak je spojenie úspešne nadviazané do menej ako max_connect_errors pokusov po prerušení predchádzajúceho spojenia, počet chýb hostiteľa sa vyrovná na nulu. Avšak akonáhle je hostiteľ zablokovaný, jediný spôsob, ako ho odblokovať, je vymazanie cache hostiteľa. Predvolená hodnota je 100. Ako je uvedené vyššie, preklad je približne nasledovný: Ak MySQL server dostane po sebe nasledujúce požiadavky od toho istého hostiteľa a všetky tieto po sebe nasledujúce požiadavky sú prerušené bez úspešného nadviazania spojenia, keď kumulatívna hodnota týchto po sebe nasledujúcich požiadaviek presiahne max_connect_errors nastavenú hodnotu, MySQL server zablokuje všetky nasledujúce požiadavky z tohto hostiteľa. Verím, že keď tieto informácie uvidíte na začiatku, budete tiež napadnutí“Mnohé po sebe nasledujúce požiadavky na spojenie z hostiteľa sú prerušené bez úspešného pripojenia”Som zmätený, v skutočnosti je to preto, že pripojenie k databáze je prerušené kvôli abnormaliám v sieti. Takéto informácie som hľadal na internete: Zdá sa, že okolo tejto premennej panuje zmätok. V skutočnosti neblokuje hostiteľov kvôli opakovaným neplatným heslám, ale kvôli prerušeným spojeniam kvôli chybám v sieti. Potom môžeme experimentovať a overiť si to sami, aby sme zistili, ktorý je správny. Vytvorte testovací účet v databáze MySQL a potom nastavíme max_connect_errors premennú na3. Potom použijeme ďalší testovací stroj na pripojenie do MySQL databázy s nesprávnym heslom, ako je uvedené nižšie, aj keď sú zadané predchádzajúce tri nesprávne heslá, štvrtý vstup nezobrazí vyššie uvedenú chybu.Potom môžete vylúčiť, že táto premenná súvisí s nesprávnym zadaním hesla. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 1045 (28000): Prístup zamietnutý pre používateľa 'test'@'mytestlnx02' (pomocou hesla: ÁNO) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 1045 (28000): Prístup zamietnutý pre používateľa 'test'@'mytestlnx02' (pomocou hesla: ÁNO) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 1045 (28000): Prístup zamietnutý pre používateľa 'test'@'mytestlnx02' (pomocou hesla: ÁNO) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 1045 (28000): Prístup zamietnutý pre používateľa 'test'@'mytestlnx02' (pomocou hesla: ÁNO) [root@mytestlnx02 tmp] # Ak IP adresa zadá nesprávne heslo, MySQL ho zaznamená do tabuľky host_cache pod databázou performance_schema. Je kumulatívne zaznamenaný v COUNT_AUTHENTICATION_ERRORS poliach nasledovne:
Podľa oficiálnych informácií je host_cache pole štatisticky považované za“Upchatie”chýb spojenia (hodnotených na základe max_connect_errors systémových premenných). Počítajú sa iba chyby protokolového handshake a používajú sa len pre autentifikované hostiteľy (HOST_VALIDATED = ÁNO). SUM_CONNECT_ERRORS Počet chýb spojenia, ktoré sa považujú za "blokujúce" (hodnotené vočimax_connect_errorssystémovej premennej). Počítajú sa iba chyby protokolového handshake, a to len pre hostiteľov, ktorí prešli validáciou (HOST_VALIDATED = ÁNO). MySQLKlient musí spustiť protokol trojnásobného handshake na nadviazanie spojenia s databázou, za normálnych okolností je tento čas veľmi krátky, ale keď sa objaví sieťová abnormalita, časový limit siete a ďalšie faktory, spôsobí to, že protokol handshake nebude možné dokončiť. MySQL má parameter connect_timeout, je to čas, kedy MySQL server spracuje mysqld na čakanie na nadviazanie spojenia, a to v priebehu sekúnd. Ak protokolový handshake nie je dokončený po uplynutí connect_timeout časového rámca, klient MySQL dostane výnimku s výnimkou podobnou tej: Strata spojenia s MySQL serverom na 'XXX', systémová chyba: errno, premenná je predvolene nastavená na 10 sekúnd:
Postavme si prípad, keď je pripojenie k databáze prerušené kvôli časovému limitu siete, použijeme príkazy netem a tc v Linuxe na simuláciu oneskorenia prenosu siete v zložitom prostredí, po nasledujúcich nastaveniach bude v tomto momente od testovacieho servera na prístup k MySQL serveru oneskorenie 11 sekúnd: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtov dát. 64 bajtov z 10.20.57.24: icmp_seq=1 ttl=62 čas=0,251 ms 64 bajtov z 10.20.57.24: icmp_seq=2 TTL=62 Čas=0,330 ms 64 bajtov z 10.20.57.24: icmp_seq=3 ttl=62 čas=0,362 ms 64 bajtov z 10.20.57.24: icmp_seq=4 ttl=62 čas=0,316 ms 64 bajtov z 10.20.57.24: icmp_seq=5 TTL=62 Čas=0,281 ms 64 bajtov z 10.20.57.24: icmp_seq=6 ttl=62 čas=0,377 ms ^C --- štatistiky pingu 10.20.57.24 --- 6 odoslaných paketov, 6 prijatých, 0% strata paketov, čas 5716 ms RTT min/avg/max/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# tc qdisc pridať dev eth0 koreňový netem oneskorenie 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtov dát. 64 bajtov z 10.20.57.24: icmp_seq=1 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=2 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=3 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=4 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=5 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=6 ttl=62 čas=11000 ms 64 bajtov z 10.20.57.24: icmp_seq=7 ttl=62 čas=11000 ms
Pripájame sa k databáze MySQL na testovacom serveri gettestlnx02, ako je uvedené nižšie (ak sa k tomuto serveru pripájate cez SSH, v tomto čase bude prevádzka na gettestlnx02 dosť pomalá). Samozrejme, môžete tiež simulovať latenciu siete na MySQL serveri, alebo môžete znížiť latenciu connect_timeout aj sieť) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 2013 (HY000): Strata spojenia s MySQL serverom pri 'čítaní autorizačného paketu', systémová chyba: 0 [root@gettestlnx02 ~] # Ako je uvedené vyššie, kvôli oneskoreniu siete viac ako 10 sekúnd zlyhalo spojenie s MySQL, v tomto momente, keď dotazujete host_cache tabuľku na MySQL serveri, uvidíte, že SUM_CONNECT_ERRORS sa zmenila na 1 a zmenil sa aj COUNT_HANDSHAKE_ERRORS1.
Potom takto hodíme trikrát opakovane a uvidíte, že SUM_CONNECT_ERRORS sa stane 3 a COUNT_HANDSHAKE_ERRORS 3. Potom použijeme príkazy netem a tc na zrušenie simulácie latencie siete na testovacom serveri a potom prejdeme na testovacie pripojenie k MySQL databáze, ako je ukázané v nasledujúcom teste: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Zadajte heslo: CHYBA 1129 (HY000): Hostiteľ '192.168.27.180' je zablokovaný kvôli mnohým chybám spojenia; Odblokujte pomocou 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
V súčasnosti sa dá postaviť“CHYBA 1129 (HY000): Hostiteľ '192.168.27.180' je zablokovaný kvôli mnohým chybám spojenia; Odblokujte pomocou 'mysqladmin flush-hosts'”Nesprávne. riešenie Vyriešená CHYBA 1129 (00000): Hostiteľ 'xxx' je zablokovaný kvôli mnohým chybám spojenia. Existuje mnoho spôsobov, ako získať chybu Unblock pomocou 'mysqladmin flush-hosts', ale niektoré sú dočasné. Dočasný plán je, že indikátory neriešia základnú príčinu. Kľúčom je opraviť sieťové chyby (ktoré často vyžadujú konzultáciu so správcami siete alebo systémovými administrátormi) Obchádzka: 1, nastavte hodnotu premennej max_connection_errors na väčšiu hodnotu
Toto dočasné riešenie je len podmienkou spustenia oneskorenia, aby bola IP zakázaná, a v zložitých prípadoch alebo pri vysokej súbežnosti je potrebné nastaviť veľkú hodnotu, inak sa ľahko znovu spustí. Okrem toho premenné nadobúdajú účinok len v aktuálnom prostredí a vypršia, ak sa znovu spustia. 2: použitieFlush hostitelia mysql> flush hosts; Dotaz OK, 0 riadkov ovplyvnených (0,00 sekundy) mysql> vyberte * z performance_schema.host_cache; Prázdna sada (0,00 sekundy) mysql> Samozrejme, môžete tiež použiť príkaz mysqladmin flush-hosts na vyčistenie cache hostov [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Zadajte heslo: Čo je to hostiteľská cache? Oficiálny úvod je nasledovný: MySQL server udržiava hostiteľskú cache v pamäti, ktorá obsahuje informácie o klientoch: IP adresu, meno hostiteľa a informácie o chybe. Server používa túto cache pre nelokálne TCP spojenia. Nepoužíva cache pre TCP spojenia nadviazané pomocou adresy loopback rozhrania (127.0.0.1 alebo ::1), ani pre pripojenia vytvorené pomocou unixového socketového súboru, pomenovaného pipe alebo zdieľaného Pamäť. Jednoducho povedané, MySQL server udržiava cache v pamäti obsahujúcu informácie o klientovi: IP adresu, meno hostiteľa, chybovú správu a podobne. Server uchováva nelokálne informácie o TCP pripojení. Neukladá do vyrovnávacej pamäte TCP pripojenia vytvorené pomocou adries rozhrania loopback (127.0.0.1 alebo ::1), ani spojenia vytvorené pomocou unixových socket súborov, pomenovaných pipeline alebo zdieľanej pamäte. Informácie o cache hostiteľa je možné vyhľadávať cez host_cache tabuľku v databáze performance_schema. 3: Nastavte premennú host_cache_size na0 V skutočnosti by som povedal, že toto je najnespoľahlivejšie riešenie, len aby MySQL server nezaznamenával informácie o cache hostiteľa. Túto metódu možno úplne ignorovať.
| 
Zverejnené 8. 4. 2019 11:01:48
|
|
|
|
