|
Recent, a fost descoperit un server MySQL din cauza unor factori speciali“ERAREA 1129 (00000): Gazda 'xxx' este blocată din cauza multor erori de conexiune. Deblochează cu 'mysqladmin flush-hosts'”După ce problema a fost rezolvată, în procesul de a învăța mai multe despre parametrii max_connect_errors, unele descrieri contradictorii ale diferitelor date de rețea m-au derutat puțin (în legătură cu această eroare, motivul esențial este că același IP a generat prea multe conexiuni întrerupte de baze de date (depășind valoarea maximă a max_connect_errors) într-un timp scurt, iar următorul este un proces de explorare a problemelor mele, analize și clarificare a îndoielilor. În primul rând, am căutat informații pe Internet, multe dintre ele jurând să introducă că dacă numărul de încercări de introducere a parolei depășește max_connect_errors variabile, MySQL va bloca această autentificare a clientului, iar apoi am găsit informațiile oficiale despre introducerea max_connect_errors, așa cum se arată mai jos, MySQL 5.6/5.7 este aceeași Dacă mai multe cereri succesive de conexiune de la o gazdă sunt întrerupte fără o conexiune reușită, serverul blochează acea gazdă de la conexiuni ulterioare. Poți debloca gazdele blocate golind cache-ul gazdelor. Pentru a face acest lucru, emiteți o instrucțiune FLUSH HOSTS sau executați o comandă mysqladmin flush-hosts. Dacă o conexiune este stabilită cu succes în mai puțin de max_connect_errors încercări după întreruperea unei conexiuni anterioare, numărul de eroare pentru gazdă este anulat la zero. Totuși, odată ce gazda este blocată, golirea cache-ului gazdei este singura modalitate de a-l debloca. Valoarea implicită este 100. După cum s-a arătat mai sus, traducerea este aproximativ următoarea: dacă serverul MySQL primește cereri consecutive de la aceeași gazdă, iar toate aceste cereri consecutive sunt întrerupte fără a stabili cu succes o conexiune, când valoarea cumulativă a acestor cereri consecutive este mai mare decât valoarea setată max_connect_errors, serverul MySQL va bloca toate cererile ulterioare de la această gazdă. Cred că atunci când vezi aceste informații la început, vei fi atacat și tu“Multe cereri de conexiune succesive de la o gazdă sunt întrerupte fără o conexiune reușită”Confuz, de fapt, acest lucru se datorează faptului că conexiunea cu baza de date este întreruptă din cauza unor anomalii în rețea. Am căutat astfel de informații pe Internet: Se pare că există confuzie în jurul acestei variabile. Nu blochează gazdele pentru parole invalide repetate, ci pentru conexiuni abortate din cauza erorilor de rețea. Atunci putem experimenta și verifica noi înșine pentru a afla care este corect. Creează un cont de test în baza de date MySQL, apoi setăm variabila max_connect_errors la3. Apoi folosim o altă mașină de test pentru a ne conecta la baza de date MySQL cu parola greșită, așa cum se arată mai jos, chiar dacă sunt introduse primele trei parole greșite, a patra intrare nu întâmpină eroarea de mai sus.Apoi poți exclude că această variabilă are legătură cu introducerea parolei greșite. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Introduceți parola: ERAREA 1045 (28000): Acces refuzat pentru utilizatorul 'test'@'mytestlnx02' (folosind parola: DA) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Introduceți parola: ERAREA 1045 (28000): Acces refuzat pentru utilizatorul 'test'@'mytestlnx02' (folosind parola: DA) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Introduceți parola: ERAREA 1045 (28000): Acces refuzat pentru utilizatorul 'test'@'mytestlnx02' (folosind parola: DA) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Introduceți parola: ERAREA 1045 (28000): Acces refuzat pentru utilizatorul 'test'@'mytestlnx02' (folosind parola: DA) [root@mytestlnx02 tmp] # De fapt, dacă un IP introduce o parolă incorectă, MySQL o va înregistra în tabelul host_cache din baza de date performance_schema. Este înregistrat cumulativ în COUNT_AUTHENTICATION_ERRORS câmpuri, după cum urmează:
Conform informațiilor oficiale, domeniul host_cache este considerat statistic ca fiind“Blocaj”de erori de conexiune (evaluate pe baza max_connect_errors variabile de sistem). Doar erorile de handshake de protocol sunt numărate și sunt folosite doar pentru gazdele autentificate (HOST_VALIDATED = DA). SUM_CONNECT_ERRORS Numărul de erori de conexiune considerate "blocare" (evaluate în raport cumax_connect_errorsvariabilă de sistem). Sunt numărate doar erorile de handshake de protocol și doar pentru gazdele care au trecut validarea (HOST_VALIDATED = DA). MySQLClientul trebuie să inițieze un protocol de handshake de trei ori pentru a stabili o conexiune cu baza de date; în condiții normale, acest timp este foarte scurt, dar odată ce apar anomaliile rețelei, timeout-ul rețelei și alți factori, protocolul de handshake nu se poate finaliza, MySQL are un parametru connect_timeout, este timpul în care serverul MySQL procesează mysqld în câteva secunde. Dacă handshake-ul de protocol încă nu este finalizat după connect_timeout interval de timp, clientul MySQL va primi o excepție cu un mesaj de excepție similar cu: Conexiunea pierdută cu serverul MySQL la "XXX", eroare de sistem: Errno, variabila este implicită la 10 secunde:
Să construim un caz în care conexiunea bazei de date este întreruptă din cauza timeout-ului rețelei, folosim comenzile netem și tc în Linux pentru a simula cazul întârzierii transmisiei rețelei într-un mediu complex, după următoarele setări, în acest moment de la serverul de testare pentru a accesa serverul MySQL, va exista o întârziere de 11 secunde: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) octeți de date. 64 octeți din 10.20.57.24: icmp_seq=1 TTL=62 timp=0,251 ms 64 octeți din 10.20.57.24: icmp_seq=2 ttl=62 timp=0.330 ms 64 octeți de la 10.20.57.24: icmp_seq=3 TTL=62 timp=0,362 ms 64 octeți din 10.20.57.24: icmp_seq=4 TTL=62 timp=0,316 ms 64 octeți din 10.20.57.24: icmp_seq=5 TTL=62 timp=0,281 ms 64 octeți din 10.20.57.24: icmp_seq=6 TTL=62 timp=0,377 ms ^C --- 20.10.57.24 statistici de ping --- 6 pachete transmise, 6 primite, 0% pierdere de pachete, timp 5716ms rtt min/avg/max/mdev = 0.251/0.319/0.377/0.047 ms [root@gettestlnx02 ~]# tc qdisc add dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) octeți de date. 64 octeți din 10.20.57.24: icmp_seq=1 TTL=62 timp=11000 ms 64 octeți din 10.20.57.24: icmp_seq=2 ttl=62 timp=11000 ms 64 octeți din 10.20.57.24: icmp_seq=3 TTL=62 timp=11000 ms 64 octeți din 10.20.57.24: icmp_seq=4 TTL=62 timp=11000 ms 64 octeți din 10.20.57.24: icmp_seq=5 TTL=62 timp=11000 ms 64 octeți de la 10.20.57.24: icmp_seq=6 TTL=62 timp=11000 ms 64 octeți din 10.20.57.24: icmp_seq=7 TTL=62 timp=11000 ms
Ne conectăm la baza de date MySQL de pe serverul de testare gettestlnx02, așa cum este prezentat mai jos (rețineți că dacă vă conectați la acest server prin ssh, va fi destul de lent de operat pe gettestlnx02 în acest moment). Desigur, poți simula și latența rețelei pe serverul MySQL sau poți reduce atât latența connect_timeout, cât și cea a rețelei) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Introduceți parola: EROARE 2013 (HY000): Conexiunea pierdută cu serverul MySQL la "citirea pachetului de autorizare", eroare de sistem: 0 [root@gettestlnx02 ~] # După cum s-a arătat mai sus, din cauza întârzierii rețelei de mai mult de 10 secunde, conexiunea către MySQL a eșuat; în acest moment, când interogați tabelul host_cache pe serverul MySQL, veți vedea că SUM_CONNECT_ERRORS a devenit 1, iar COUNT_HANDSHAKE_ERRORS s-a schimbat și el1.
Apoi aruncăm astfel de trei ori de mai multe ori și vei vedea că SUM_CONNECT_ERRORS devine 3, iar COUNT_HANDSHAKE_ERRORS devine 3. Apoi folosim comenzi netem și tc pentru a anula simularea latentiei rețelei pe serverul de test, iar apoi trecem la conexiunea de test către baza de date MySQL, așa cum este arătat în următorul test: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Introduceți parola: EROARE 1129 (HY000): Gazda '192.168.27.180' este blocată din cauza multor erori de conexiune; Deblochează cu 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
În acest moment, poate fi construit“EROARE 1129 (HY000): Gazda '192.168.27.180' este blocată din cauza multor erori de conexiune; Deblochează cu 'mysqladmin flush-hosts'”Greșit. soluție EROARE 1129 rezolvată (00000): Gazda 'xxx' este blocată din cauza multor erori de conexiune. Există multe moduri de a obține eroarea Unblock cu 'mysqladmin flush-hosts', dar unele sunt temporare. Planul temporar este ca indicatorii să nu abordeze cauza principală. Cheia este corectarea erorilor de rețea (care adesea necesită consultanță pentru administratori de rețea sau de sistem) Soluție de ocolire: 1, setează valoarea variabilei max_connection_errors la o valoare mai mare
Această soluție temporară este doar o condiție de declanșare a întârzierii pentru ca proprietatea intelectuală să fie interzisă, iar în cazuri complexe sau cu concurență mare, este necesar să se stabilească o valoare mare, altfel va fi declanșată ușor din nou. În plus, variabilele au efect doar asupra mediului curent și vor expira dacă sunt repornite. 2: utilizaregazde flush mysql> gazdele flush; Interogare OK, 0 rânduri afectate (0,00 sec) mysql> selectează * din performance_schema.host_cache; Set gol (0,00 secunde) mysql> Desigur, poți folosi și comanda mysqladmin flush-hosts pentru a curăța informațiile cache-ului gazdei [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Introduceți parola: Deci, ce este cache-ul gazdelor? Introducerea oficială este următoarea: Serverul MySQL menține un cache gazdă în memorie care conține informații despre clienți: adresă IP, numele gazdei și informații despre eroare. Serverul folosește acest cache pentru conexiuni TCP non-locale. Nu folosește cache-ul pentru conexiuni TCP stabilite folosind o adresă de interfață loopback (127.0.0.1 sau ::1), nici pentru conexiuni stabilite folosind un fișier socket Unix, o țeavă denumită sau partajată Memorie. Pe scurt, serverul MySQL menține un cache în memorie care conține informații despre client: adresă IP, nume gazdă, mesaj de eroare etc. Serverul stochează în cache informații de conexiune TCP non-locale. Nu stochează în cache conexiuni TCP realizate folosind adrese de interfață loopback (127.0.0.1 sau::1), nici conexiuni realizate folosind fișiere socket Unix, pipeline-uri denumite sau memorie partajată. Informațiile cache-ului gazdei pot fi interogate prin tabelul host_cache din baza de date performance_schema. 3: Setează variabila host_cache_size la0 De fapt, aș spune că aceasta este cea mai nesigură soluție, doar ca serverul MySQL să nu înregistreze informațiile cache-ului gazdei. Această metodă poate fi complet ignorată.
| 
Postat pe 08.04.2019 11:01:48
|
|
|
|
