|
Äskettäin MySQL-palvelin on kohdattu joidenkin erityisten tekijöiden vuoksi“VIRHE 1129 (00000): Isäntä 'xxx' on estetty monien yhteysvirheiden vuoksi. Poista esto 'mysqladmin flush-hostsilla'”Kun ongelma oli ratkaistu, oppiessani lisää parametrista max_connect_errors, ristiriitaiset kuvaukset eri verkkodatasta hämmensivät minua hieman (tämän virheen osalta olennainen syy on se, että sama IP-osoite tuotti liian monta keskeytettyä tietokantayhteyttä (ylittäen max_connect_errors:n maksimiarvon) lyhyessä ajassa, ja seuraava on prosessi, jossa tutkin ongelmiani, analysoin ongelmia ja selvennämme epäilyksiä. Ensiksi etsin tietoa internetistä, joista monet vannovat ilmoittavansa, että jos salasanasyöttöyritysten määrä ylittää max_connect_errors muuttujaa, MySQL estää tämän asiakaskirjautumisen, ja sitten löysin viralliset tiedot max_connect_errors:n käyttöönotosta, kuten alla on esitetty, MySQL 5.6/5.7 on sama Jos yli tämä määrä peräkkäisiä yhteyspyyntöjä isännältä keskeytyy ilman onnistunutta yhteyttä, palvelin estää isännän jatkamasta yhteyksiä. Voit poistaa eston estoutuneista isännöistä tyhjentämällä isäntävälimuistin. Tätä varten anna FLUSH HOSTS -lause tai suorita mysqladmin flush-hosts -komento. Jos yhteys muodostetaan onnistuneesti alle max_connect_errors yrityksessä edellisen yhteyden keskeytyksen jälkeen, isännän virhemäärä nollataan. Kuitenkin, kun isäntä on estetty, isäntävälimuistin tyhjentäminen on ainoa tapa avata se. Oletusarvo on 100. Kuten yllä on esitetty, käännös on suunnilleen seuraava: Jos MySQL-palvelin vastaanottaa peräkkäisiä pyyntöjä samalta isännältä ja kaikki nämä peräkkäiset pyynnöt keskeytyvät ilman, että yhteys on onnistunut, kun näiden peräkkäisten pyyntöjen kumulatiivinen arvo on suurempi kuin max_connect_errors asetettu arvo, MySQL-palvelin estää kaikki myöhemmät pyynnöt tältä isännältä. Uskon, että kun näet tämän tiedon alussa, sinua hyökätään myös“Monet peräkkäiset yhteyspyynnöt isännältä keskeytyvät ilman onnistunutta yhteyttä”Hämmentynyt, itse asiassa tämä johtuu siitä, että tietokantayhteys keskeytetään verkon poikkeavuuksien vuoksi. Etsin tällaista tietoa internetistä: Vaikuttaa siltä, että tästä muuttujasta on epäselvyyttä. Se ei varsinaisesti estä isäntiä toistuville virheellisille salasanoille, vaan verkkovirheiden vuoksi keskeytyneille yhteyksille. No, sitten voimme itse kokeilla ja varmistaa, mikä niistä on oikea. Luo testitili MySQL-tietokantaan ja asetamme sitten max_connect_errors-muuttujaksi3. Sitten käytämme toista testikonetta yhdistääksemme MySQL-tietokantaan väärällä salasanalla, kuten alla on esitetty; vaikka edelliset kolme väärää salasanaa syötettäisiin, neljäs syöte ei kohtaa yllä mainittua virhettä.Silloin voit sulkea pois, että tällä muuttujalla on jotain tekemistä väärän salasanan syöttämisen kanssa. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Syötä salasana: VIRHE 1045 (28000): Pääsy evätty käyttäjältä 'test'@'mytestlnx02' (käyttäen salasanaa: KYLLÄ) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Syötä salasana: VIRHE 1045 (28000): Pääsy evätty käyttäjältä 'test'@'mytestlnx02' (käyttäen salasanaa: KYLLÄ) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Syötä salasana: VIRHE 1045 (28000): Pääsy evätty käyttäjältä 'test'@'mytestlnx02' (käyttäen salasanaa: KYLLÄ) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Syötä salasana: VIRHE 1045 (28000): Pääsy evätty käyttäjältä 'test'@'mytestlnx02' (käyttäen salasanaa: KYLLÄ) [root@mytestlnx02 tmp] # Itse asiassa, jos IP-osoite syöttää väärän salasanan, MySQL tallentaa sen host_cache-taulukkoon performance_schema-tietokannan alla. Se on yhteensä kirjattu COUNT_AUTHENTICATION_ERRORS kenttään seuraavasti:
Virallisten tietojen mukaan host_cache ala katsotaan tilastollisesti seuraavasti“Tukos”yhteysvirheistä (arvioitu max_connect_errors järjestelmämuuttujien perusteella). Vain protokollan kättelyvirheet lasketaan ja niitä käytetään vain autentikoiduille isännöille (HOST_VALIDATED = KYLLÄ). SUM_CONNECT_ERRORS Yhteysvirheiden määrä, jotka katsotaan "estäväksi" (arvioitumax_connect_errorsjärjestelmämuuttuja). Vain protokollan kättelyvirheet lasketaan, ja vain isännille, jotka läpäisivät validoinnin (HOST_VALIDATED = KYLLÄ). MySQLAsiakkaan täytyy käynnistää kolmikertainen handshake-protokolla yhteyden muodostamiseksi tietokantaan, normaalisti tämä aika on hyvin lyhyt, mutta kun verkon poikkeavuus, verkon aikakatkaisu ja muut tekijät ilmenevät, se estää handshake-protokollan valmistumisen, MySQL:llä on parametri connect_timeout, jolloin MySQL-palvelinprosessi mysqld odottaa yhteyden muodostumista sekunneissa. Jos protokollan kättelyä ei vieläkään suoriteta connect_timeout aikakehyksen jälkeen, MySQL-asiakas saa poikkeuksen, jossa on poikkeusviesti, joka muistuttaa seuraavaa: Yhteys MySQL-palvelimeen katkesi kohdassa 'XXX', järjestelmävirhe: errno, muuttuja oletuksena on 10 sekuntia:
Rakennetaan tapaus, jossa tietokantayhteys keskeytyy verkon aikakatkaisun vuoksi, käytämme Linuxin netem- ja tc-komentoja simuloidaksemme verkon siirtoviivetapausta monimutkaisessa ympäristössä, seuraavien asetusten jälkeen, jolloin testipalvelimelta MySQL-palvelimelle pääsyyn tulee 11 sekunnin viive: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) tavua dataa. 64 tavua alkaen 10.20.57.24: icmp_seq=1 ttl=62 time=0,251 ms 64 tavua alkaen 10.20.57.24: icmp_seq=2 ttl=62 time=0,330 ms 64 tavua alkaen 10.20.57.24: icmp_seq=3 ttl=62 time=0,362 ms 64 tavua alkaen 10.20.57.24: icmp_seq=4 ttl=62 aika=0,316 ms 64 tavua alkaen 10.20.57.24: icmp_seq=5 ttl=62 time=0,281 ms 64 tavua alkaen 10.20.57.24: icmp_seq=6 ttl=62 time=0,377 ms ^C --- 10.20.57.24 ping-tilastot --- 6 pakettia lähetetty, 6 vastaanotettu, 0 % pakettihäviö, aika 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) tavua dataa. 64 tavua alkaen 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=2 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=3 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=4 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=5 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=6 ttl=62 time=11000 ms 64 tavua alkaen 10.20.57.24: icmp_seq=7 ttl=62 time=11000 ms
Yhdistämme MySQL-tietokantaan testipalvelimella gettestlnx02 kuten alla on esitetty (huomaa, että jos yhdistät tähän palvelimeen ssh:n kautta, gettestlnx02:n käyttö on tällä hetkellä melko hidasta). Tietenkin voit myös simuloida verkon viivettä MySQL-palvelimella, tai tehdä sekä connect_timeout että verkon viiveestä pienempiä) [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p Syötä salasana: ERROR 2013 (HY000): Yhteys MySQL-palvelimelle menetettiin kohdassa 'reading authorization packet', järjestelmävirhe: 0 [root@gettestlnx02 ~] # Kuten yllä on esitetty, yli 10 sekunnin verkkoviiveen vuoksi yhteys MySQL:ään epäonnistui, ja kun kysyt host_cache-taulua MySQL-palvelimella, näet, että SUM_CONNECT_ERRORS on muuttunut 1:ksi ja myös COUNT_HANDSHAKE_ERRORS on muuttunut1.
Sitten heitämme näin kolme kertaa toistuvasti, ja näet, että SUM_CONNECT_ERRORS muuttuu 3:ksi ja COUNT_HANDSHAKE_ERRORS kolmeksi. Sitten käytämme netem- ja tc-komentoja peruuttaaksemme verkon viivesimulaation testipalvelimella, ja siirrymme testiyhteyteen MySQL-tietokantaan, kuten seuraavassa testissä on esitetty: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mySQL -h10.20.57.24 -utest -p Syötä salasana: ERROR 1129 (HY000): Isäntä '192.168.27.180' on estetty monien yhteysvirheiden vuoksi; Poista esto 'mysqladmin flush-hostsilla' [root@gettestlnx02 ~] #
Tällöin se voidaan rakentaa“ERROR 1129 (HY000): Isäntä '192.168.27.180' on estetty monien yhteysvirheiden vuoksi; Poista esto 'mysqladmin flush-hostsilla'”Väärin. ratkaisu Ratkaistu ERROR 1129 (00000): Isäntä 'xxx' on estetty monien yhteysvirheiden vuoksi. On monia tapoja saada virhe Unblock 'mysqladmin flush-hosts' -menetelmällä, mutta jotkut ovat väliaikaisia. Väliaikainen suunnitelma on, että indikaattorit eivät ota huomioon juurisyytä. Avain on korjata verkkovirheet (jotka usein vaativat verkonvalvojan tai järjestelmänvalvojan konsultointia) Kiertotie: 1, aseta muuttujan arvoksi max_connection_errors suurempi arvo
Tämä väliaikainen ratkaisu on vain viiveen laukaisuehto, jonka vuoksi IP:n kieltäminen tehdään, ja monimutkaisissa tapauksissa tai korkeassa samanaikaisuudessa on tarpeen asettaa suuri arvo, muuten arvo aktivoituu helposti uudelleen. Lisäksi muuttujat vaikuttavat vain nykyisessä ympäristössä ja vanhenevat, jos ne käynnistetään uudelleen. 2: käyttöFlush-isännät mySQL> Flush Hosts; Kysely OK, 0 riviä vaikutti (0,00 sekuntia) mysql> valitse * performance_schema.host_cache; Tyhjä setti (0,00 s) MySQL> Tietenkin voit myös käyttää mysqladmin flush-hosts -komentoa isäntävälimuistitietojen puhdistamiseen [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Syötä salasana: Mikä siis on isäntävälimuisti? Virallinen johdanto on seuraava: MySQL-palvelin ylläpitää isäntävälimuistia muistissa, joka sisältää tietoja asiakkaista: IP-osoite, isäntänimi ja virhetiedot. Palvelin käyttää tätä välimuistia ei-paikallisiin TCP-yhteyksiin. Se ei käytä välimuistia TCP-yhteyksille, jotka on muodostettu loopback-liitäntäosoitteella (127.0.0.1 tai ::1), eikä yhteyksille, jotka muodostetaan Unix-socket-tiedostolla, nimetyllä putkella tai jaetulla muisto. Yksinkertaisesti sanottuna MySQL-palvelin ylläpitää muistissa välimuistia, joka sisältää asiakastietoja: IP-osoite, isäntänimi, virheilmoitus jne. Palvelin välimuistittaa ei-paikalliset TCP-yhteystiedot. Se ei välimuistita TCP-yhteyksiä, jotka on tehty loopback-liitäntäosoitteilla (127.0.0.1 tai ::1), eikä yhteyksiä, jotka on tehty Unix-socket-tiedostoilla, nimetyillä putkistoilla tai jaetulla muistilla. Isäntävälimuistitietoja voi hakea performance_schema-tietokannan host_cache-taulun kautta. 3: Aseta muuttuja host_cache_size muotoon0 Itse asiassa sanoisin, että tämä on epäluotettavin ratkaisu, jotta MySQL-palvelin ei kirjaa isäntävälimuistitietoja. Tämän menetelmän voi täysin sivuuttaa.
| 
Julkaistu 8.4.2019 11.01.48
|
|
|
|
