|
Nedavno smo naleteli na MySQL strežnik zaradi posebnih dejavnikov“NAPAKA 1129 (00000): Gostitelj 'xxx' je blokiran zaradi številnih napak v povezavi. Odblokirajte z 'mysqladmin flush-hosts'”Ko je bila težava rešena, so me med raziskovanjem parametra max_connect_errors nekoliko zmedli nekateri nasprotujoči si opisi različnih omrežnih podatkov (pri tej napaki je bistvo, da je isti IP v kratkem času ustvaril preveč prekinjenih povezav z bazo podatkov (ki presegajo največjo vrednost max_connect_errors), in sledi proces raziskovanja mojih težav, analize in razjasnitve dvomov. Najprej sem iskal nekaj informacij na internetu, od katerih mnogi prisegajo, da če bo število poskusov vnosa gesla preseglo max_connect_errors spremenljivk, bo MySQL blokiral to prijavo odjemalca, nato pa sem našel uradne informacije o uvedbi max_connect_errors, kot je prikazano spodaj, je MySQL 5.6/5.7 enak Če je več kot toliko zaporednih zahtevkov za povezavo iz enega gostitelja prekinjenih brez uspešne povezave, strežnik blokira to gostiteljsko povezavo za nadaljnje povezave. Blokirane gostitelje lahko odblokiraš tako, da izprazniš predpomnilnik gostiteljev. Za to izdajte ukaz FLUSH HOSTS ali izvedite ukaz mysqladmin flush-hosts. Če je povezava uspešno vzpostavljena v manj kot max_connect_errors poskusih po prekinitvi prejšnje povezave, se število napak gostitelja zmanjša na nič. Vendar pa, ko je gostitelj blokiran, je edini način za odblokiranje predpomnilnika gostitelja izpraznitev predpomnilnika. Privzeto je 100. Kot je prikazano zgoraj, je prevod približno naslednji: Če MySQL strežnik prejme zaporedne zahteve od istega gostitelja in so vse te zaporedne zahteve prekinjene brez uspešne vzpostavitve povezave, bo MySQL strežnik, ko je kumulativna vrednost teh zaporednih zahtev večja od max_connect_errors nastavljene vrednosti, MySQL strežnik blokiral vse nadaljnje zahteve tega gostitelja. Verjamem, da boš, ko vidiš te informacije na začetku, tudi ti napaden“Veliko zaporednih zahtevkov za povezavo s strani gostitelja je prekinjenih brez uspešne povezave”Zmedeno je, pravzaprav zato, ker je povezava z bazo podatkov prekinjena zaradi omrežnih nepravilnosti. Na internetu sem iskal takšne informacije: Zdi se, da je okoli te spremenljivke zmeda. Gostiteljev ne blokira zaradi ponavljajočih se neveljavnih gesel, ampak zaradi prekinjenih povezav zaradi omrežnih napak. No, potem lahko sami eksperimentiramo in preverimo, da ugotovimo, katera je pravilna. Ustvarite testni račun v MySQL bazi podatkov in nato nastavimo max_connect_errors spremenljivko na3. Nato uporabimo drugo testno napravo za povezavo z MySQL bazo podatkov z napačnim geslom, kot je prikazano spodaj; tudi če vnesemo prejšnje tri napačne gesla, četrti vnos ne naleti na zgornjo napako.Nato lahko izključite, da ima ta spremenljivka nekaj opraviti z napačnim vnosom gesla. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 1045 (28000): Dostop zavrnjen za uporabnika 'test'@'mytestlnx02' (z uporabo gesla: DA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 1045 (28000): Dostop zavrnjen za uporabnika 'test'@'mytestlnx02' (z uporabo gesla: DA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 1045 (28000): Dostop zavrnjen za uporabnika 'test'@'mytestlnx02' (z uporabo gesla: DA) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 1045 (28000): Dostop zavrnjen za uporabnika 'test'@'mytestlnx02' (z uporabo gesla: DA) [root@mytestlnx02 TMP] # Pravzaprav, če IP vnese napačno geslo, ga MySQL zabeleži v tabelo host_cache pod performance_schema bazo podatkov. Kumulativno je zabeležen v COUNT_AUTHENTICATION_ERRORS poljih na naslednji način:
Po uradnih podatkih je področje host_cache statistično obravnavano kot“Zamašitev”napak povezave (ocenjene na podlagi max_connect_errors sistemskih spremenljivk). Štejejo se le napake protokolnega handshakea in se uporabljajo le za avtentificirane gostitelje (HOST_VALIDATED = DA). SUM_CONNECT_ERRORS Število napak povezave, ki se štejejo za "blokirajoče" (ocenjeno glede namax_connect_errorssistemske spremenljivke). Štejejo se le napake protokola pri rokovanju in to le za gostitelje, ki so prestali validacijo (HOST_VALIDATED = DA). MySQLOdjemalec mora sprožiti protokol trikratnega rokovanja, da vzpostavi povezavo z bazo podatkov; v normalnih okoliščinah je ta čas zelo kratek, vendar ko se pojavijo omrežne nepravilnosti, časovni izpad omrežja in drugi dejavniki, protokol roke ne more biti dokončan. MySQL ima parameter connect_timeout, to je čas, ko MySQL strežnik počaka na vzpostavitev povezave, v nekaj sekundah. Če protokol še vedno ni zaključen po connect_timeout časovnem okviru, bo MySQL odjemalec prejel izjemo z izjemnim sporočilom, podobnim kot: Izguba povezave z MySQL strežnikom na 'XXX', sistemska napaka: errno, spremenljivka je privzeto 10 sekund:
Sestavimo primer, kjer je povezava baze podatkov prekinjena zaradi časovne omejitve omrežja, uporabimo ukaza netem in tc v Linuxu za simulacijo zakasnitve prenosa omrežja v kompleksnem okolju, po naslednjih nastavitvah bo v tem trenutku od testnega strežnika do dostopa do MySQL strežnika zakasnitev 11 sekund: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bajtov podatkov. 64 bajtov iz 10.20.57.24: icmp_seq=1 tt=62 čas=0,251 ms 64 bajtov iz 10.20.57.24: icmp_seq=2 TTL=62 Čas=0,330 ms 64 bajtov iz 10.20.57.24: icmp_seq=3 tt=62 čas=0,362 ms 64 bajtov iz 10.20.57.24: icmp_seq=4 tt=62 čas=0,316 ms 64 bajtov iz 10.20.57.24: icmp_seq=5 tt=62 čas=0,281 ms 64 bajtov iz 10.20.57.24: icmp_seq=6 TTL=62 Čas=0,377 ms ^C --- 10.20.57.24 ping statistika --- 6 poslanih paketov, 6 prejetih, 0% izguba paketov, čas 5716 ms 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) bajtov podatkov. 64 bajtov iz 10.20.57.24: icmp_seq=1 TTL=62 Time=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=2 tt=62 čas=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=3 TTL=62 Čas=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=4 tt=62 čas=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=5 ttl=62 čas=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=6 TTL=62 Čas=11000 ms 64 bajtov iz 10.20.57.24: icmp_seq=7 tt=62 čas=11000 ms
Povežemo se z MySQL bazo podatkov na testnem strežniku gettestlx02, kot je prikazano spodaj (upoštevajte, da če se na ta strežnik povezujete prek SSH, bo delovanje na gettestlx02 trenutno precej počasno). Seveda lahko tudi simuliraš omrežno zakasnitev na MySQL strežniku ali pa zmanjšaš tako connect_timeout kot omrežno zakasnitev) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 2013 (HY000): Izgubljena povezava z MySQL strežnikom pri 'branju avtorizacijskega paketa', sistemska napaka: 0 [root@gettestlnx02 ~] # Kot je prikazano zgoraj, je zaradi omrežne zakasnitve več kot 10 sekund povezava z MySQL odpovedala; v tem trenutku, ko poizvedujete tabelo host_cache na MySQL strežniku, boste videli, da je SUM_CONNECT_ERRORS postal 1, COUNT_HANDSHAKE_ERRORS pa se je prav tako spremenil1.
Nato tako vržemo trikrat in boste videli, da SUM_CONNECT_ERRORS postane 3, COUNT_HANDSHAKE_ERRORS pa 3. Nato uporabimo ukaza netem in tc, da prekličemo simulacijo omrežne zakasnitve na testnem strežniku, nato pa gremo na testno povezavo z MySQL bazo podatkov, kot je prikazano v naslednjem testu: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Vnesite geslo: NAPAKA 1129 (HY000): Gostitelj '192.168.27.180' je blokiran zaradi številnih napak v povezavi; Odblokirajte z 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Trenutno jo je mogoče sestaviti“NAPAKA 1129 (HY000): Gostitelj '192.168.27.180' je blokiran zaradi številnih napak v povezavi; Odblokirajte z 'mysqladmin flush-hosts'”Napačno. rešitev Rešena NAPAKA 1129 (00000): Gostitelj 'xxx' je blokiran zaradi številnih napak v povezavi. Obstaja veliko načinov, kako dobiti napako Unblock z 'mysqladmin flush-hosts', vendar so nekateri začasni. Začasni načrt je, da kazalniki ne rešujejo osnovnega vzroka. Ključ je v odpravi omrežnih napak (ki pogosto zahtevajo posvetovanje z omrežnimi ali sistemskimi administratorji) Rešitev: 1, nastavi vrednost spremenljivke max_connection_errors na večjo vrednost
Ta začasna rešitev je le pogoj, ki sproži zamik za prepoved IP, in v zapletenih primerih ali visoki sočasnosti je potrebno nastaviti veliko vrednost, sicer se bo enostavno ponovno sprožil. Poleg tega spremenljivke začnejo veljati le v trenutnem okolju in potečejo, če se ponovno zaženejo. 2: uporabaIzpiranje gostiteljev mySQL> Flush gostitelji; Poizvedba OK, 0 vrstic prizadetih (0,00 sekunde) mysql> izberi * iz performance_schema.host_cache; Prazna množica (0,00 sekunde) mysql> Seveda lahko uporabite tudi ukaz mysqladmin flush-hosts za čiščenje podatkov o predpomnilniku hostov [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Vnesite geslo: Kaj torej je host cache? Uradni uvod je naslednji: MySQL strežnik vzdržuje gostiteljski predpomnilnik v pomnilniku, ki vsebuje informacije o odjemalcih: IP naslov, ime gostitelja in informacije o napakah. Strežnik uporablja ta predpomnilnik za nelokalne TCP povezave. Ne uporablja predpomnilnika za TCP povezave, vzpostavljene z naslovom loopback vmesnika (127.0.0.1 ali ::1), niti za povezave, vzpostavljene z Unix socket datoteko, imenovano cev ali deljeno Spomin. Preprosto povedano, MySQL strežnik vzdržuje predpomnilnik v pomnilniku, ki vsebuje informacije o odjemalcu: IP naslov, ime gostitelja, sporočilo o napaki itd. Strežnik predpomni informacije o nelokalnih TCP povezavah. Ne predpomni TCP povezav, vzpostavljenih z naslovi vmesnika loopback (127.0.0.1 ali ::1), niti povezav, ki so narejene z Unix socket datotekami, imenovanimi cevovodi ali deljenim pomnilnikom. Informacije o predpomnilniku gostitelja je mogoče poizvedovati prek tabele host_cache v performance_schema bazi podatkov. 3: Nastavi spremenljivko host_cache_size na0 Pravzaprav bi rekel, da je to najbolj nezanesljiva rešitev, da MySQL strežnik ne beleži podatkov o predpomnilniku gostitelja. To metodo je mogoče popolnoma prezreti.
| 
Objavljeno na 8. 04. 2019 11:01:48
|
|
|
|
