|
Hiljuti puututi kokku MySQL serveriga mõnede eritegurite tõttu“VIGA 1129 (00000): Host 'xxx' on blokeeritud paljude ühendusvigade tõttu. Eemalda blokeering 'mysqladmin flush-hosts' abil”Pärast probleemi lahendamist, parameetri max_connect_errors kohta rohkem õppides, segasid mind mõned vastuolulised kirjeldused erinevatest võrguandmetest (selle vea peamine põhjus on see, et sama IP genereeris lühikese aja jooksul liiga palju katkestatud andmebaasiühendusi (ületades maksimaalse max_connect_errors väärtuse), ning järgnevalt uuritakse minu probleeme, analüüsin probleeme ja selgitan kahtlusi. Esiteks otsisin internetist infot, millest paljud lubavad, et kui parooli sisestamise katsete arv ületab max_connect_errors muutujat, blokeerib MySQL selle kliendi sisselogimise, ja siis leidsin ametliku info max_connect_errors kasutuselevõtu kohta, nagu allpool näidatud – MySQL 5.6/5.7 on sama Kui rohkem kui see arv järjestikust ühendustaotlust hostilt katkestatakse ilma eduka ühenduseta, blokeerib server selle hosti edasised ühendused. Blokeeritud hoste saab blokeeringu eemaldada, tühjendades hosti vahemälu. Selleks väljasta FLUSH HOSTS lause või käivita käsk mysqladmin flush-hosts. Kui ühendus luuakse edukalt vähem kui max_connect_errors katsega pärast eelmise ühenduse katkestust, kustutatakse hosti veanumber nulli. Kui host on blokeeritud, on hosti vahemälu tühjendamine ainus viis selle blokeeringu eemaldamiseks. Vaikimisi on 100. Nagu eespool näidatud, on tõlge ligikaudu järgmine: Kui MySQL server saab järjestikku päringuid samalt hostilt ja kõik need järjestikused päringud katkestatakse ilma ühenduse loomiseta, siis kui nende järjestikuste päringute kumulatiivne väärtus on suurem kui max_connect_errors seatud väärtus, blokeerib MySQL server kõik järgnevad päringud sellelt hostilt. Usun, et kui näed seda infot alguses, rünnatakse ka sind“Paljud järjestikused ühendustaotlused hostilt katkestatakse ilma eduka ühenduseta”Segaduses on see tegelikult sellepärast, et andmebaasi ühendus katkestatakse võrgu kõrvalekallete tõttu. Otsisin sellist infot internetist: Tundub, et selle muutuja ümber on segadus. See ei blokeeri hoste korduvate vigaste paroolide puhul, vaid võrguvigade tõttu katkestatud ühenduste puhul. Siis saame ise katsetada ja kontrollida, et teada saada, milline neist on õige. Loo MySQL andmebaasis testkonto ja seejärel määrame max_connect_errors muutujaks3. Seejärel kasutame teist testmasinat, et ühenduda MySQL andmebaasiga vale parooliga, nagu allpool näidatud – isegi kui sisestatakse eelnevad kolm vale parooli, ei esine neljas sisend ülaltoodud viga.Siis võid välistada, et see muutuja on seotud vale parooli sisestamisega. [root@mytestlnx02 tmp]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 1045 (28000): Juurdepääs keelatud kasutajale 'test'@'mytestlnx02' (kasutades parooli: JAH) [root@mytestlnx02 tmp]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 1045 (28000): Juurdepääs keelatud kasutajale 'test'@'mytestlnx02' (kasutades parooli: JAH) [root@mytestlnx02 tmp]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 1045 (28000): Juurdepääs keelatud kasutajale 'test'@'mytestlnx02' (kasutades parooli: JAH) [root@mytestlnx02 tmp]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 1045 (28000): Juurdepääs keelatud kasutajale 'test'@'mytestlnx02' (kasutades parooli: JAH) [root@mytestlnx02 tmp] # Tegelikult, kui IP sisestab vale parooli, salvestab MySQL selle host_cache tabelisse performance_schema andmebaasi all. See on kokku registreeritud COUNT_AUTHENTICATION_ERRORS väljal järgmiselt:
Ametliku teabe kohaselt peetakse host_cache valdkonda statistiliselt järgmiselt“Ummistus”ühendusvigade (hinnatud max_connect_errors süsteemi muutujate põhjal). Arvestatakse ainult protokolli käepigistusvigu ja neid kasutatakse ainult autentitud hostide puhul (HOST_VALIDATED = JAH). SUM_CONNECT_ERRORS Ühendusvigade arv, mida peetakse "blokeerimiseks" (hinnatudmax_connect_errorssüsteemimuutuja). Arvestatakse ainult protokolli käepigistusvead ja ainult hostide puhul, kes läbisid valideerimise (HOST_VALIDATED = JAH). MySQLKlient peab käivitama kolmekordse käepigistusprotokolli, et luua ühendus andmebaasiga, tavatingimustes on see aeg väga lühike, kuid kui ilmnevad võrgu kõrvalekalle, võrgu ajapiirang ja muud tegurid, põhjustab see käepigistuse protokolli lõpetamatust, MySQL-il on parameeter connect_timeout, see on aeg, mil MySQL serveri protsess mysqld ootab ühenduse loomist sekunditega. Kui protokolli käepigistus ei ole connect_timeout aja jooksul ikka lõpetatud, saab MySQL klient erandi koos erandsõnumiga, mis on sarnane: Kaotatud ühendus MySQL serveriga aadressil 'XXX', süsteemiviga: errno, muutuja vaikimisi on 10 sekundit:
Loome juhtumi, kus andmebaasi ühendus katkestatakse võrgu ajapiirangu tõttu, kasutame Linuxis netem ja tc käske, et simuleerida võrgu edastuse viivituse juhtumit keerulises keskkonnas, pärast järgmisi seadeid, sel hetkel testserverist MySQL serverile pääsemiseks on 11-sekundiline viivitus: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) baiti andmeid. 64 baiti alates 20.10.57.24: icmp_seq=1 ttl=62 aeg=0,251 ms 64 baiti alates 20.10.57.24: icmp_seq=2 ttl=62 aeg=0,330 ms 64 baiti alates 20.10.57.24: icmp_seq=3 ttl=62 aeg=0,362 ms 64 baiti alates 20.10.57.24: icmp_seq=4 ttl=62 aeg=0,316 ms 64 baiti alates 20.10.57.24: icmp_seq=5 ttl=62 aeg=0,281 ms 64 baiti alates 10.20.57.24: icmp_seq=6 ttl=62 aeg=0,377 ms ^C --- 10.20.57.24 pingistatistika --- 6 paketti edastatud, 6 vastu võetud, 0% pakettide kadu, aeg 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) baiti andmeid. 64 baiti alates 20.10.57.24: icmp_seq=1 ttl=62 aeg=11000 ms 64 baiti alates 20.10.57.24: icmp_seq=2 ttl=62 aeg=11000 ms 64 baiti alates 20.10.57.24: icmp_seq=3 ttl=62 aeg=11000 ms 64 baiti alates 20.10.57.24: icmp_seq=4 ttl=62 aeg=11000 ms 64 baiti alates 20.10.57.24: icmp_seq=5 ttl=62 aeg=11000 ms 64 baiti alates 10.20.57.24: icmp_seq=6 ttl=62 aeg=11000 ms 64 baiti alates 20.10.57.24: icmp_seq=7 ttl=62 aeg=11000 ms
Me ühendume MySQL andmebaasiga testserveris gettestlnx02, nagu allpool näidatud (pane tähele, et kui ühendud selle serveriga ssh kaudu, on gettestlnx02 peal praegu üsna aeglane). Loomulikult saab simuleerida võrgulatentsust ka MySQL serveris või teha nii connect_timeout kui ka võrgulatentsuse väiksemaks) [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 2013 (HY000): Katkes ühenduse MySQL serveriga aadressil 'loitsuspaketi lugemine', süsteemiviga: 0 [root@gettestlnx02 ~] # Nagu eespool näidatud, võrgu viivituse tõttu üle 10 sekundi ebaõnnestus ühendus MySQL-iga; sel hetkel, kui pärid MySQL serveri host_cache tabelit, näed, et SUM_CONNECT_ERRORS on muutunud 1-ks ja ka COUNT_HANDSHAKE_ERRORS on muutunud1.
Seejärel viskame seda kolm korda järjest ja näed, et SUM_CONNECT_ERRORS muutub 3-ks ja COUNT_HANDSHAKE_ERRORS 3-ks. Seejärel kasutame netem ja tc käske, et tühistada võrgu latentsuse simulatsioon testserveris ning seejärel läheme testühenduse juurde MySQL andmebaasiga, nagu näidatud järgmises testis: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p Sisesta parool: VIGA 1129 (HY000): Host '192.168.27.180' on blokeeritud paljude ühendusvigade tõttu; Eemalda blokeering 'MysqLadmin Flush-hosts' [root@gettestlnx02 ~] #
Sel ajal saab selle konstrueerida“VIGA 1129 (HY000): Host '192.168.27.180' on blokeeritud paljude ühendusvigade tõttu; Eemalda blokeering 'MysqLadmin Flush-hosts'”Vale. lahus Lahendatud VIGA 1129 (00000): Host 'xxx' on blokeeritud paljude ühendusvigade tõttu. On palju viise, kuidas saada vea Unblock koos 'mysqladmin flush-hosts'iga, kuid mõned on ajutised. Ajutine plaan on, et indikaatorid ei käsitle algpõhjust. Oluline on parandada võrguvead (mis sageli nõuavad võrguadministraatorite või süsteemiadministraatoritega konsulteerimist) Lahendus: 1, määrab muutuja väärtuseks max_connection_errors suurema väärtuse
See ajutine lahendus on lihtsalt viivituse käivitamise tingimus, et IP keelatakse, ning keerulistel juhtudel või kõrge samaaegsuse korral on vaja määrata suur väärtus, vastasel juhul aktiveerub see kergesti uuesti. Lisaks jõustuvad muutujad ainult praeguses keskkonnas ja aeguvad, kui neid taaskäivitada. 2: kasutusPesuperemehed MySQL > Flush hostid; Päring OK, 0 rida mõjutatud (0,00 sek) mySQL> vali * performance_schema.host_cache'ist; Tühi komplekt (0,00 sek) MySQL> Loomulikult saad kasutada ka käsku mysqladmin flush-hosts, et puhastada hosti vahemälu infot [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Sisesta parool: Mis siis on hosti vahemälu? Ametlik sissejuhatus on järgmine: MySQL server hoiab mälus hostivahemälu, mis sisaldab teavet klientide kohta: IP-aadress, hostinimi ja veateavet. Server kasutab seda vahemälu mitte-lokaalsete TCP ühenduste jaoks. See ei kasuta vahemälu TCP-ühenduste jaoks, mis on loodud loopback-liidese aadressiga (127.0.0.1 või ::1), ega ühenduste jaoks, mis on loodud Unix socket-faili, nimega toru või jagatud mälestus. Lihtsalt öeldes hoiab MySQL server mälus vahemälu, mis sisaldab kliendi infot: IP-aadress, hostinimi, veateadet jne. Server salvestab mitte-kohaliku TCP ühenduse info. See ei vahemällu salvesta TCP-ühendusi, mis on tehtud loopback-liidese aadresside (127.0.0.1 või ::1) abil, ega ühendusi, mis on tehtud Unix socket-failide, nimetatud torujuhtmete või jagatud mäluga. Hosti vahemälu infot saab pärida performance_schema andmebaasi host_cache tabeli kaudu. 3: Seadke muutuja host_cache_size kujule0 Tegelikult ütleksin, et see on kõige ebausaldusväärsem lahendus, lihtsalt selleks, et MySQL server ei logiks hosti vahemälu infot. Seda meetodit võib täielikult ignoreerida.
| 
Postitatud 08.04.2019 11:01:48
|
|
|
|
