|
Nemrégiben egy MySQL szerverrel találkoztak néhány különleges tényező miatt“HIBA 1129 (00000): A 'xxx' hoszt blokkolva van sok kapcsolati hiba miatt. Oldd fel a 'mysqladmin flush-hosts' segítségével”Miután a probléma megoldódott, miközben többet tanultam a max_connect_errors paraméterről, néhány ellentmondásos hálózati adatleírás kissé összezavart (ezzel a hibával kapcsolatban az alapvető ok, hogy ugyanaz az IP túl sok megszakított adatbázis-kapcsolatot generált (ami meghaladja a max_connect_errors maximális értékét) rövid idő alatt, és a következő folyamat a problémáim elemzése, elemzése és a kétségek tisztázása. Először is kerestem néhány információt az interneten, amelyek közül sokan esküszöm, hogy bejelentik, hogy ha a jelszóbeviteli próbálkozások száma meghaladja max_connect_errors változót, akkor a MySQL blokkolja ezt a kliensbejelentkezést, majd megtaláltam a hivatalos információkat a max_connect_errors bevezetéséről, ahogy az lentebb látható, a MySQL 5.6/5.7 ugyanaz. Ha egy hosttól ennél több egymást követő kapcsolati kérést megszakítanak siker nélkül, a szerver blokkolja az adott hostot további kapcsolatoktól. A blokkolt hosztokat a host cache leürítésével lehet megszüntetni. Ehhez adj ki egy FLUSH HOSTS utasítást vagy hajts végre egy mysqladmin flush-hosts parancsot. Ha a kapcsolatot kevesebb mint max_connect_errors próbálkozás után sikeresen létrehozzák a korábbi kapcsolat megszakítása után, a gazda hibaszáma nullára csökken. Azonban ha egy host blokkolásra kerül, az egyetlen módja a hoszt gyorsítótár eltávolításának megszüntetésének. Az alapértelmezett érték 100. Ahogy fentebb is látható, a fordítás nagyjából a következő: Ha a MySQL szerver ugyanazzal a hosztolóval érkező egymást követő kéréseket kap, és ezek mind megszakítják anélkül, hogy sikeresen kapcsolatot hoztak létre, akkor amikor ezeknek a egymást követő kéréseknek az összege nagyobb, mint az max_connect_errors beállított érték, a MySQL szerver blokkolja az összes további kérést ettől a hoszttól. Úgy hiszem, ha ezt az információt az elején látod, téged is megtámadnak“Számos egymást követő kapcsolatkérés egy hárdétól megszakítódik sikeresen való kapcsolat nélkül”Zavarba ejtve, ez azért van, mert az adatbázis-kapcsolat hálózati rendellenességek miatt szakadt meg. Az interneten kerestem ilyen információkat: Úgy tűnik, zavar van ezzel a változóval kapcsolatban. Nem igazán blokkolja a hosztokat ismétlődő érvénytelen jelszavak esetén, hanem hálózati hibák miatt megszakított kapcsolatok esetén. Akkor kipróbálhatjuk és ellenőrizhetjük magunk, hogy kiderüljön, melyik a helyes. Létrehozunk egy tesztfiókot a MySQL adatbázisban, majd beállítjuk a max_connect_errors változót3. Ezután egy másik tesztgépet használunk, hogy rossz jelszóval csatlakozzunk a MySQL adatbázishoz, ahogy az lentebb is látható, még ha az előző három rossz jelszót is beírjuk, a negyedik bemenet nem találkozik a fenti hibával.Így kizárhatod, hogy ez a változó köze van a rossz jelszóbejegyzéshez. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 1045 (28000): Hozzáférés megtagadva a 'test'@'mytestlnx02' felhasználótól (jelszóval: IGEN) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 1045 (28000): Hozzáférés megtagadva a 'test'@'mytestlnx02' felhasználótól (jelszóval: IGEN) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 1045 (28000): Hozzáférés megtagadva a 'test'@'mytestlnx02' felhasználótól (jelszóval: IGEN) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 1045 (28000): Hozzáférés megtagadva a 'test'@'mytestlnx02' felhasználótól (jelszóval: IGEN) [root@mytestlnx02 tmp] # Valójában, ha egy IP hibás jelszót ír be, a MySQL azt a performance_schema adatbázis alatti host_cache táblába rögzíti. Összesített COUNT_AUTHENTICATION_ERRORS mezőn a következőképpen rögzítik:
A hivatalos információk szerint a host_cache területet statisztikailag a következőképpen tekintik“Elzáródás”kapcsolati hibák (max_connect_errors rendszerváltozó alapján értékelve). Csak a protokoll kézfogási hibáit számolják, és csak autentikált hosztokhoz használják (HOST_VALIDATED = IGEN). SUM_CONNECT_ERRORS A "blokkolónak" minősülő kapcsolati hibák száma (az összehasonlítva amax_connect_errorsrendszerváltozó). Csak a protokoll kézfogási hibáit számolják, és csak azoknál a hosztoknál, amelyek átmentek az ellenőrzésen (HOST_VALIDATED = IGEN). MySQLAz ügyfélnek háromszoros kézfogási protokollt kell indítania, hogy kapcsolatot teremtsen az adatbázissal, normál körülmények között ez az idő nagyon rövid, de amikor megjelenik a hálózati rendellenesség, a hálózati időtúllépés és egyéb tényezők, az a kézfogás protokoll befejezésének lehetetlenségét eredményezi, MySQL-nek van connect_timeout paramétere, ez az idő, amikor a MySQL szerver processe mysqld másodpercek alatt várja a kapcsolat létrejöttét. Ha a protokoll kézfogása a connect_timeout időkeret után sem fejeződik be, a MySQL kliens kivételt kap egy hasonló kivételüzenettel, amely a következőképpen szól: Elvesztette a kapcsolatot a MySQL szerverrel a 'XXX'-nél, rendszerhiba: errno, a változó alapértelmezettként 10 másodpercre változik:
Építsünk egy esetet, ahol az adatbázis-kapcsolat hálózati időkilépés miatt szakad meg, a netem és tc parancsokat használjuk Linux módjában, hogy szimuláljuk a hálózati átviteli késleltetés esetét egy összetett környezetben, a következő beállítások után, ekkor a tesztszervertől a MySQL szerverhez való hozzáféréshez 11 másodperces késés lesz: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bájt adat. 64 bájt 10.20.57.24-től: icmp_seq=1 ttl=62 idő=0,251 ms 64 bájt 10.20.57.24-től: icmp_seq=2 ttl=62 idő=0,330 ms 64 bájt 20.20.57.24-től: icmp_seq=3 ttl=62 idő=0,362 ms 64 bájt 20.20.57.24-től: icmp_seq=4 ttl=62 time=0,316 ms 64 bájt 10.20.57.24-től: icmp_seq=5 ttl=62 idő=0,281 ms 64 bájt 20.20.57.24-től: icmp_seq=6 ttl=62 idő=0,377 ms ^C --- 10.20.2024 ping statisztikák --- 6 csomag továbbítva, 6 kapott, 0% csomagvesztés, idő 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) bájt adat. 64 bájt 20.20.57.24-től: icmp_seq=1 ttl=62 time=11000 ms 64 bájt 10.20.57.24-től: icmp_seq=2 ttl=62 time=11000 ms 64 bájt 10.20.57.24-től: icmp_seq=3 ttl=62 time=11000 ms 64 bájt 20.20.57.24-től: icmp_seq=4 ttl=62 time=11000 ms 64 bájt 20.20.57.24-től: icmp_seq=5 ttl=62 time=11000 ms 64 bájt 10.20.57.24-től: icmp_seq=6 ttl=62 idő=11000 ms 64 bájt 10.20.57.24-től: icmp_seq=7 ttl=62 time=11000 ms
A MySQL adatbázishoz csatlakozunk a tesztszerveren gettestlnx02 ahogy az alábbiakban látható (figyelem, hogy ha ehhez a szerverhez SSH-n keresztül csatlakozol, akkor elég lassú lesz a gettestlnx02-n működni). Természetesen szimulálhatod a hálózati késleltetést a MySQL szerveren is, vagy csökkentheted a connect_timeout és a hálózati késleltetést is) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 2013 (HY000): Elvesztette a kapcsolatot a MySQL szerverrel 'authorization packet olvasás' esetén, rendszerhiba: 0 [root@gettestlnx02 ~] # Ahogy fentebb is látható, a több mint 10 másodperces hálózati késés miatt a MySQL kapcsolat meghibásodott, ekkor, amikor a MySQL szerveren a host_cache táblát kérdezed, akkor látod, hogy a SUM_CONNECT_ERRORS 1-re változott, és a COUNT_HANDSHAKE_ERRORS is változott1.
Ezután háromszor ismételten így dobjuk, és látjuk, hogy a SUM_CONNECT_ERRORS 3-as, a COUNT_HANDSHAKE_ERRORS pedig 3-as lesz. Ezután netem és tc parancsokat használunk a hálózati késleltetési szimuláció megszüntetésére a tesztszerveren, majd a MySQL adatbázis tesztkapcsolatához megyünk, ahogy az alábbi teszt is mutatja: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Írd be a jelszót: HIBA 1129 (HY000): A '192.168.27.180' gép sok kapcsolati hiba miatt blokkolódik; Oldd fel a blokkolást a 'MysqLadmin flush-hosts' segítségével [root@gettestlnx02 ~] #
Ebben az időben már megépíthető“HIBA 1129 (HY000): A '192.168.27.180' gép sok kapcsolati hiba miatt blokkolódik; Oldd fel a blokkolást a 'MysqLadmin flush-hosts' segítségével”Tévedés. megoldás Megoldott HIBA 1129 (00000): A 'xxx' hoszt blokkolva van sok kapcsolati hiba miatt. Számos módja van annak, hogy 'mysqladmin flush-hosts' hibát kapj, de néhány ideiglenes. Az ideiglenes terv az, hogy a mutatók nem kezelik a gyökérokot. A kulcs a hálózati hibák javítása (amelyek gyakran hálózati vagy rendszergazdákkal kell konzultálni) Megoldás: 1, a változó értékét max_connection_errors nagyobb értékre állítsuk be
Ez az ideiglenes megoldás csak egy késleltetési kiváltó feltétel az IP tiltásához, és összetett esetekben vagy magas egyidejű esetben nagy értéket kell beállítani, különben könnyen újra bevált. Ráadásul a változók csak a jelenlegi környezetben lépnek életbe, és lejárnak, ha újraindítják őket. 2: használatÖsztönös gazdagépek MySQL> Öblítési Gazdagépek; Lekérdezés rendben, 0 sor érintett (0,00 másodperc) MySQL> válassz * a performance_schema.host_cache közül; Üres készlet (0,00 másodperc) MySQL> Természetesen használhatod a mysqladmin flush-hosts parancsot is, hogy tisztítsd a host cache adatait [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Írd be a jelszót: Szóval mi az a host cache? A hivatalos bevezető a következő: A MySQL szerver egy hoszt gyorstárt tart fenn a memóriában, amely információkat tartalmaz az ügyfelekről: IP-cím, gazdanév és hibainformációk. A szerver ezt a gyorsítótárt használja nem helyi TCP kapcsolatokhoz. Nem használja a gyorstárt a TCP kapcsolatokhoz, amelyeket loopback interfész címmel hoznak létre (127.0.0.1 vagy ::1), sem a Unix socket fájl, név szerinti cső vagy közös kapcsolat révén hoznak létre Emlék. Egyszerűen fogalmazva, a MySQL szerver egy gyorsítótárt tart fenn a memóriában, amely kliensinformációkat: IP-cím, gazdanév, hibaüzenet stb. A szerver nem helyi TCP kapcsolati információkat gyorsít el. Nem gyorsítótározza azokat TCP kapcsolatokat, amelyeket loopback interfész címekkel (127.0.0.1 vagy ::1) készítettek, sem Unix socket fájlokkal, nevelt pipeline-okkal vagy megosztott memóriával készült kapcsolatokat. A hista gyorsítótár adatai a performance_schema adatbázis host_cache tábláján keresztül lekérdezhetők. 3: Állítsuk be a host_cache_size változót0 Valójában azt mondanám, hogy ez a legmegbízhatatlanabb megoldás, csak azért, hogy a MySQL szerver ne logold be a host cache adatait. Ezt a módszert teljesen figyelmen kívül lehet hagyni.
| 
Közzétéve 2019. 04. 08. 11:01:48
|
|
|
|
