|
Neseniai MySQL serveris buvo aptiktas dėl kai kurių ypatingų veiksnių“KLAIDA 1129 (00000): Pagrindinis kompiuteris "xxx" užblokuotas dėl daugybės ryšio klaidų. Atblokuokite naudodami "mysqladmin flush-hosts"”Išsprendus problemą, sužinojus daugiau apie parametrų max_connect_errors, kai kurie prieštaringi skirtingų tinklo duomenų aprašymai mane šiek tiek supainiojo (apie šią klaidą, esminė priežastis yra ta, kad tas pats IP per trumpą laiką sugeneravo per daug nutrūkusių duomenų bazės ryšių (viršijančių maksimalią max_connect_errors vertę), o toliau pateikiamas mano problemų tyrimo, problemų analizės ir abejonių išaiškinimo procesas. Visų pirma, internete ieškojau informacijos, iš kurios daugelis prisiekia pristatyti, kad jei slaptažodžio įvedimo bandymų skaičius viršys max_connect_errors kintamuosius, MySQL užblokuos šį kliento prisijungimą, o tada radau oficialią informaciją apie max_connect_errors įvedimą, kaip parodyta žemiau, MySQL 5.6/5.7 yra tas pats Jei daugiau nei tiek daug iš eilės einančių ryšio užklausų iš pagrindinio kompiuterio nutraukiama be sėkmingo ryšio, serveris blokuoja tą pagrindinį kompiuterį nuo tolesnių ryšių. Galite atblokuoti užblokuotus pagrindinius kompiuterius išvalydami pagrindinio kompiuterio talpyklą. Norėdami tai padaryti, išleiskite FLUSH HOSTS sakinį arba vykdykite mysqladmin flush-hosts komandą. Jei ryšys sėkmingai užmezgamas per mažiau nei max_connect_errors bandymų po ankstesnio ryšio nutraukimo, pagrindinio kompiuterio klaidų skaičius išvalomas iki nulio. Tačiau užblokavus pagrindinį kompiuterį, vienintelis būdas jį atblokuoti yra pagrindinio kompiuterio talpyklos išvalymas. Numatytoji reikšmė yra 100. Kaip parodyta aukščiau, vertimas yra maždaug toks: Jei MySQL serveris gauna iš eilės užklausas iš to paties pagrindinio kompiuterio ir visos šios iš eilės einančios užklausos nutraukiamos sėkmingai neužmezgus ryšio, kai šių iš eilės užklausų kaupiamoji vertė yra didesnė už max_connect_errors nustatytą reikšmę, MySQL serveris užblokuos visas vėlesnes šio pagrindinio kompiuterio užklausas. Manau, kad kai pamatysite šią informaciją pradžioje, būsite užpulti ir“Daugelis iš eilės einančių ryšio užklausų iš pagrindinio kompiuterio nutraukiamos be sėkmingo ryšio”Supainiota, tiesą sakant, taip yra todėl, kad duomenų bazės ryšys nutraukiamas dėl tinklo anomalijų. Tokios informacijos ieškojau internete: Atrodo, kad yra painiavos aplink šį kintamąjį. Jis tikrai neblokuoja pakartotinių negaliojančių slaptažodžių, bet nutrauktų ryšių dėl tinklo klaidų. Na, tada mes galime eksperimentuoti ir patys patikrinti, kad išsiaiškintume, kuris iš jų yra teisingas. Sukurkite bandomąją paskyrą "MySQL" duomenų bazėje, tada nustatome kintamąjį max_connect_errors į3. Tada naudojame kitą bandomąjį įrenginį, kad prisijungtume prie MySQL duomenų bazės naudodami neteisingą slaptažodį, kaip parodyta toliau, net jei įvedami ankstesni trys neteisingi slaptažodžiai, ketvirtasis įvestis nesusiduria su aukščiau pateikta klaida.Tada galite atmesti, kad šis kintamasis yra susijęs su neteisingu slaptažodžio įvedimu. [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 1045 (28000): prieiga uždrausta vartotojui "test"@"mytestlnx02" (naudojant slaptažodį: TAIP) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 1045 (28000): prieiga uždrausta vartotojui "test"@"mytestlnx02" (naudojant slaptažodį: TAIP) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 1045 (28000): prieiga uždrausta vartotojui "test"@"mytestlnx02" (naudojant slaptažodį: TAIP) [root@mytestlnx02 tmp]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 1045 (28000): prieiga uždrausta vartotojui "test"@"mytestlnx02" (naudojant slaptažodį: TAIP) [root@mytestlnx02 tmp] # Tiesą sakant, jei IP įveda neteisingą slaptažodį, MySQL įrašys jį į host_cache lentelę performance_schema duomenų bazėje. Jis bendrai įrašomas COUNT_AUTHENTICATION_ERRORS laukuose taip:
Remiantis oficialia informacija, host_cache laukas statistiškai laikomas“Užsikimšimas”ryšio klaidų (įvertintų pagal max_connect_errors sistemos kintamuosius). Skaičiuojamos tik protokolo rankos paspaudimo klaidos ir naudojamos tik autentifikuotiems pagrindiniams kompiuteriams (HOST_VALIDATED = TAIP). SUM_CONNECT_ERRORS Ryšio klaidų, kurios laikomos "blokuojančiomis", skaičius (įvertintas pagalmax_connect_errorssistemos kintamasis). Skaičiuojamos tik protokolo rankos paspaudimo klaidos ir tik pagrindiniams kompiuteriams, kurie praėjo patvirtinimą (HOST_VALIDATED = TAIP). MySQLKlientas turi inicijuoti tris kartus rankos paspaudimo protokolą, kad užmegztų ryšį su duomenų baze, įprastomis aplinkybėmis šis laikas yra labai trumpas, tačiau atsiradus tinklo anomalijai, tinklo skirtajam laikui ir kitiems veiksniams, rankos paspaudimo protokolas negalės būti užbaigtas, MySQL turi parametrą connect_timeout, laikas MySQL serverio procesui mysqld laukti, kol bus užmegztas ryšys, per kelias sekundes. Jei protokolo rankos paspaudimas vis tiek nebaigtas praėjus connect_timeout laikotarpiui, MySQL klientas gaus išimtį su išimties pranešimu, panašiu į: Prarastas ryšys su MySQL serveriu "XXX", sistemos klaida: Klaida, numatytasis kintamasis yra 10 sekundžių:
Sukurkime atvejį, kai duomenų bazės ryšys nutrūksta dėl tinklo skirtojo laiko, mes naudojame "Linux" komandas "netem" ir "tc", kad imituotume tinklo perdavimo delsos atvejį sudėtingoje aplinkoje, atlikus šiuos nustatymus, šiuo metu iš bandomojo serverio, kad pasiektumėte "MySQL" serverį, bus 11 sekundžių vėlavimas: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) baitai duomenų. 64 baitai iš 10.20.57.24: icmp_seq=1 ttl=62 laikas=0.251 ms 64 baitai iš 10.20.57.24: icmp_seq=2 ttl=62 laikas=0.330 ms 64 baitai iš 10.20.57.24: icmp_seq=3 ttl=62 laikas=0.362 ms 64 baitai iš 10.20.57.24: icmp_seq=4 ttl=62 laikas=0.316 ms 64 baitai iš 10.20.57.24: icmp_seq=5 ttl=62 laikas=0.281 ms 64 baitai iš 10.20.57.24: icmp_seq=6 ttl=62 laikas=0.377 ms ^C --- 10.20.57.24 ping statistikos --- 6 perduoti paketai, 6 gauti, 0% paketų praradimas, laikas 5716ms rtt min/avg/max/mdev = 0,251/0,319/0,377/0,047 ms [root@gettestlnx02 ~]# tc qdisc pridėti dev eth0 root netem delsa 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) baitai duomenų. 64 baitai iš 10.20.57.24: icmp_seq=1 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=2 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=3 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=4 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=5 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=6 ttl=62 laikas=11000 ms 64 baitai iš 10.20.57.24: icmp_seq=7 ttl=62 laikas=11000 ms
Mes prisijungiame prie MySQL duomenų bazės bandymo serveryje gettestlnx02, kaip parodyta žemiau (atkreipkite dėmesį, kad jei jungiatės prie šio serverio per ssh, šiuo metu gettestlnx02 veiks gana lėtai.) Žinoma, taip pat galite imituoti tinklo delsą MySQL serveryje arba sumažinti connect_timeout ir tinklo delsą) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 2013 (HY000): Prarastas ryšys su MySQL serveriu "skaitymo autorizacijos paketas", sistemos klaida: 0 [root@gettestlnx02 ~] # Kaip parodyta aukščiau, dėl daugiau nei 10 sekundžių tinklo vėlavimo nepavyko prisijungti prie "MySQL", šiuo metu, kai užklausiate host_cache lentelę "MySQL" serveryje, pamatysite, kad SUM_CONNECT_ERRORS tapo 1, o COUNT_HANDSHAKE_ERRORS taip pat pasikeitė1.
Tada mes taip metame tris kartus pakartotinai ir pamatysite, kad SUM_CONNECT_ERRORS tampa 3, o COUNT_HANDSHAKE_ERRORS tampa 3. Tada mes naudojame netem ir tc komandas, kad atšauktume tinklo delsos modeliavimą bandymo serveryje, tada einame prie bandomojo ryšio su MySQL duomenų baze, kaip parodyta šiame teste: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Įveskite slaptažodį: KLAIDA 1129 (HY000): pagrindinis kompiuteris "192.168.27.180" užblokuotas dėl daugybės ryšio klaidų; Atblokuokite naudodami "mysqladmin flush-hosts" [root@gettestlnx02 ~] #
Šiuo metu jis gali būti sukonstruotas“KLAIDA 1129 (HY000): pagrindinis kompiuteris "192.168.27.180" užblokuotas dėl daugybės ryšio klaidų; Atblokuokite naudodami "mysqladmin flush-hosts"”Neteisingai. sprendimas Išspręsta KLAIDA 1129 (00000): Pagrindinis kompiuteris "xxx" užblokuotas dėl daugybės ryšio klaidų. Yra daug būdų, kaip gauti klaidą Atblokuoti naudojant "mysqladmin flush-hosts", tačiau kai kurie yra laikini. Laikinas planas yra toks, kad rodikliai nepašalina pagrindinės priežasties. Svarbiausia yra ištaisyti tinklo klaidas (dėl kurių dažnai reikia pasikonsultuoti su tinklo administratoriais arba sistemos administratoriais) Sprendimo būdas: 1, nustatykite kintamojo max_connection_errors reikšmę į didesnę reikšmę
Šis laikinas sprendimas yra tik vėlavimo sąlyga, kad IP būtų uždraustas, o sudėtingais atvejais ar dideliu sutapimu būtina nustatyti didelę vertę, kitaip ji lengvai vėl bus suaktyvinta. Be to, kintamieji įsigalioja tik dabartinėje aplinkoje ir nustos galioti, jei jie bus paleisti iš naujo. 2: naudotipraplovimo pagrindiniai kompiuteriai mysql> praplovimo pagrindiniai kompiuteriai; Užklausa gerai, paveikta 0 eilučių (0,00 sek.) mysql> pasirinkite * iš performance_schema.host_cache; Tuščias rinkinys (0,00 sek.) mysql> Žinoma, taip pat galite naudoti komandą mysqladmin flush-hosts, kad išvalytumėte pagrindinio kompiuterio talpyklos informaciją [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Įveskite slaptažodį: Taigi, kas yra pagrindinio kompiuterio talpykla? Oficialus įvadas yra toks: MySQL serveris atmintyje palaiko pagrindinio kompiuterio talpyklą, kurioje yra informacija apie klientus: IP adresas, pagrindinio kompiuterio pavadinimas ir informacija apie klaidas. Serveris naudoja šią talpyklą nevietiniams TCP ryšiams. Jis nenaudoja talpyklos TCP ryšiams, užmegztiems naudojant loopback sąsajos adresą (127.0.0.1 arba ::1), arba ryšiams, užmegztiems naudojant Unix lizdo failą, pavadintą vamzdį arba bendrai naudojamą atmintis. Paprasčiau tariant, MySQL serveris atmintyje palaiko talpyklą, kurioje yra kliento informacija: IP adresas, pagrindinio kompiuterio pavadinimas, klaidos pranešimas ir kt. Serveris talpykloje saugo nevietinę TCP ryšio informaciją. Ji nesaugo TCP ryšių, sukurtų naudojant loopback sąsajos adresus (127.0.0.1 arba::1), arba ryšių, sukurtų naudojant Unix lizdo failus, pavadintus vamzdynus ar bendrą atmintį. Pagrindinio kompiuterio talpyklos informacijos galima užklausti naudojant performance_schema duomenų bazės host_cache lentelę. 3: Nustatykite kintamąjį host_cache_size į0 Tiesą sakant, sakyčiau, kad tai yra pats nepatikimiausias sprendimas, kad "MySQL" serveris neregistruotų pagrindinio kompiuterio talpyklos informacijos. Šio metodo galima visiškai nepaisyti.
| 
Paskelbta 2019-04-08 11:01:48
|
|
|
|
