|
Nylig ble en MySQL-server oppdaget på grunn av noen spesielle faktorer“FEIL 1129 (00000): Vert 'xxx' er blokkert på grunn av mange tilkoblingsfeil. Opphev blokkeringen med 'mysqladmin flush-hosts'”Etter at problemet var løst, i prosessen med å lære mer om parameteren max_connect_errors, forvirret noen motstridende beskrivelser av ulike nettverksdata meg litt (om denne feilen er hovedårsaken at den samme IP-en genererte for mange avbrutte databaseforbindelser (som oversteg maksimal verdi på max_connect_errors) på kort tid, og det følgende er en prosess med å utforske problemene mine, analysere problemer og avklare tvil. Først søkte jeg etter noe informasjon på Internett, mange av dem sverger på å introdusere at hvis antall passordforsøk overstiger max_connect_errors variabler, vil MySQL blokkere denne klientinnloggingen, og så fant jeg den offisielle informasjonen om innføringen av max_connect_errors, som vist nedenfor, er MySQL 5.6/5.7 det samme Hvis flere påfølgende tilkoblingsforespørsler fra en vert avbrytes uten vellykket tilkobling, blokkerer serveren den verten fra videre tilkoblinger. Du kan fjerne blokkeringen av blokkerte verter ved å tømme vertens cache. For å gjøre dette, utfør en FLUSH HOSTS-setning eller kjør en mysqladmin flush-hosts-kommando. Hvis en tilkobling etableres med suksess innen færre enn max_connect_errors forsøk etter at en tidligere tilkobling ble avbrutt, slettes feiltellingen for verten til null. Men når en vert er blokkert, er tømmelse av vertens cache den eneste måten å fjerne blokkeringen på. Standard er 100. Som vist ovenfor, er oversettelsen omtrent som følger: Hvis MySQL-serveren mottar påfølgende forespørsler fra samme vert, og alle disse påfølgende forespørslene avbrytes uten å etablere en forbindelse, vil den kumulative verdien av disse påfølgende forespørslene være større enn max_connect_errors satt verdi, og alle påfølgende forespørsler fra denne verten blokkeres. Jeg tror at når du ser denne informasjonen i begynnelsen, vil du også bli angrepet“Mange påfølgende tilkoblingsforespørsler fra en vert blir avbrutt uten en vellykket tilkobling”Forvirret, faktisk er dette fordi databasetilkoblingen avbrytes på grunn av nettverksavvik. Jeg søkte etter slik informasjon på Internett: Det virker som det er forvirring rundt denne variabelen. Den blokkerer egentlig ikke verter for gjentatte ugyldige passord, men for avbrutte tilkoblinger på grunn av nettverksfeil. Vel, da kan vi eksperimentere og verifisere det selv for å finne ut hvilken som er riktig. Opprett en testkonto i MySQL-databasen, og så setter vi max_connect_errors-variabelen til3. Deretter bruker vi en annen testmaskin for å koble til MySQL-databasen med feil passord, som vist nedenfor, selv om de tre forrige feilpassordene er skrevet inn, opplever ikke den fjerde inputen feilen ovenfor.Da kan du utelukke at denne variabelen har noe med feil passordregistrering å gjøre. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 1045 (28000): Tilgang nektet for bruker 'test'@'mytestlnx02' (bruker passord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 1045 (28000): Tilgang nektet for bruker 'test'@'mytestlnx02' (bruker passord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 1045 (28000): Tilgang nektet for bruker 'test'@'mytestlnx02' (bruker passord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 1045 (28000): Tilgang nektet for bruker 'test'@'mytestlnx02' (bruker passord: JA) [root@mytestlnx02 tmp] # Faktisk, hvis en IP skriver inn et feil passord, vil MySQL registrere det i host_cache tabellen under performance_schema-databasen. Den er kumulativt registrert i COUNT_AUTHENTICATION_ERRORS feltene som følger:
Ifølge offisiell informasjon regnes host_cache feltet statistisk som“Blokkering”av tilkoblingsfeil (vurdert basert på max_connect_errors systemvariabler). Kun protokollhåndtrykkfeil telles og brukes kun for autentiserte verter (HOST_VALIDATED = JA). SUM_CONNECT_ERRORS Antallet tilkoblingsfeil som anses som "blokkerende" (vurdert motmax_connect_errorssystemvariabel). Kun protokollhåndtrykkfeil telles, og kun for verter som bestod valideringen (HOST_VALIDATED = JA). MySQLKlienten må starte en tre-gangs håndtrykkprotokoll for å etablere en forbindelse med databasen, under normale omstendigheter, denne tiden er svært kort, men når nettverksavvik, nettverkstidsavbrudd og andre faktorer oppstår, vil det føre til at håndtrykkprotokollen ikke kan fullføres, MySQL har en parameter connect_timeout, det er tid for MySQL-serverprosessen mysqld å vente på at tilkoblingen skal etableres, på sekunder. Hvis protokollhåndtrykket fortsatt ikke er fullført etter den connect_timeout tidsrammen, vil MySQL-klienten motta et unntak med en unntaksmelding lik som: Mistet tilkoblingen til MySQL-serveren på 'XXX', systemfeil: Errno, variabelen er standard 10 sekunder:
La oss konstruere et tilfelle der databasetilkoblingen avbrytes på grunn av nettverkstidsavbrudd, vi bruker netem- og tc-kommandoene i Linux for å simulere forsinkelsen i nettverksoverføringen i et komplekst miljø, etter følgende innstillinger, på dette tidspunktet fra testserveren til å få tilgang til MySQL-serveren, vil det være en forsinkelse på 11 sekunder: [root@gettestlnx02 ~]# ping 20.10.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) byte data. 64 byte fra 10.20.57.24: icmp_seq=1 ttl=62 time=0.251 ms 64 byte fra 10.20.57.24: icmp_seq=2 ttl=62 tid=0,330 ms 64 bytes fra 10.20.57.24: icmp_seq=3 ttl=62 time=0.362 ms 64 byte fra 10.20.57.24: icmp_seq=4 ttl=62 time=0.316 ms 64 byte fra 10.20.57.24: icmp_seq=5 ttl=62 time=0.281 ms 64 byte fra 10.20.57.24: icmp_seq=6 ttl=62 time=0.377 ms ^C --- 10.20.57.24 pingstatistikk --- 6 pakker sendt, 6 mottatt, 0 % pakketap, tid 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 20.10.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) byte data. 64 byte fra 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 byte fra 10.20.57.24: icmp_seq=2 ttl=62 tid=11000 ms 64 byte fra 10.20.57.24: icmp_seq=3 ttl=62 tid=11000 ms 64 byte fra 10.20.57.24: icmp_seq=4 ttl=62 time=11000 ms 64 byte fra 10.20.57.24: icmp_seq=5 ttl=62 tid=11000 ms 64 byte fra 10.20.57.24: icmp_seq=6 ttl=62 time=11000 ms 64 byte fra 10.20.57.24: icmp_seq=7 ttl=62 tid=11000 ms
Vi kobler til MySQL-databasen på testserveren gettestlnx02 som vist nedenfor (merk at hvis du kobler til denne serveren via ssh, vil det være ganske tregt å operere på gettestlnx02 akkurat nå.) Selvfølgelig kan du også simulere nettverksforsinkelse på MySQL-serveren, eller du kan gjøre både connect_timeout- og nettverkslatens mindre) [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 2013 (HY000): Mistet tilkoblingen til MySQL-serveren ved 'leseautorisasjonspakke', systemfeil: 0 [root@gettestlnx02 ~] # Som vist ovenfor, på grunn av nettverksforsinkelsen på mer enn 10 sekunder, feilet tilkoblingen til MySQL, og på dette tidspunktet, når du spør i host_cache-tabellen på MySQL-serveren, vil du se at SUM_CONNECT_ERRORS har blitt 1, og COUNT_HANDSHAKE_ERRORS har også endret seg1.
Så kaster vi dette tre ganger gjentatte ganger, og du vil se at SUM_CONNECT_ERRORS blir 3, og COUNT_HANDSHAKE_ERRORS blir 3. Deretter bruker vi netem- og tc-kommandoer for å avbryte nettverkslatenssimuleringen på testserveren, og går deretter til testtilkoblingen til MySQL-databasen, som vist i følgende test: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Skriv inn passord: FEIL 1129 (HY000): Vert '192.168.27.180' er blokkert på grunn av mange tilkoblingsfeil; Opphev blokkeringen med 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
På dette tidspunktet kan den konstrueres“FEIL 1129 (HY000): Vert '192.168.27.180' er blokkert på grunn av mange tilkoblingsfeil; Opphev blokkeringen med 'mysqladmin flush-hosts'”Feil. løsning Løst FEIL 1129 (00000): Vert 'xxx' er blokkert på grunn av mange tilkoblingsfeil. Det finnes mange måter å få feilen Unblock med 'mysqladmin flush-hosts' på, men noen er midlertidige. Den midlertidige planen er at indikatorene ikke adresserer den egentlige årsaken. Nøkkelen er å rette nettverksfeil (som ofte krever konsultasjon med nettverksadministratorer eller systemadministratorer) Løsning: 1, sett verdien av variabelen max_connection_errors til en høyere verdi
Denne midlertidige løsningen er bare en forsinkelsesutløsende betingelse for at IP-en skal forbys, og i komplekse tilfeller eller høy samtidighet er det nødvendig å sette en høy verdi, ellers vil den lett bli utløst igjen. I tillegg påvirker variablene kun det nåværende miljøet, og utløper hvis de startes på nytt. 2: brukFlush-verter MySQL> flush hosts; Spørring OK, 0 rader påvirket (0,00 sek) mysql> velg * fra performance_schema.host_cache; Tom mengde (0,00 sek) MySQL> Selvfølgelig kan du også bruke kommandoen mysqladmin flush-hosts for å rydde opp i cache-informasjonen til vertene [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Skriv inn passord: Så hva er vertscache? Den offisielle introduksjonen er som følger: MySQL-serveren opprettholder en vertscache i minnet som inneholder informasjon om klienter: IP-adresse, vertsnavn og feilinformasjon. Serveren bruker denne cachen for ikke-lokale TCP-tilkoblinger. Den bruker ikke cachen for TCP-tilkoblinger etablert med en loopback-grensesnittadresse (127.0.0.1 eller ::1), eller for tilkoblinger etablert via en Unix-socketfil, navngitt pipe eller delt minne. Enkelt sagt opprettholder MySQL-serveren en cache i minnet som inneholder klientinformasjon: IP-adresse, vertsnavn, feilmelding osv. Serveren cacher informasjon om ikke-lokal TCP-tilkobling. Den bufrer ikke TCP-tilkoblinger laget ved bruk av loopback-grensesnittadresser (127.0.0.1 eller::1), eller forbindelser laget ved bruk av Unix-socketfiler, navngitte pipelines eller delt minne. Vertscache-informasjon kan forespørres gjennom host_cache tabellen i performance_schema-databasen. 3: Sett variabelen host_cache_size til0 Faktisk vil jeg si at dette er den mest upålitelige løsningen, bare for å få MySQL-serveren til å ikke logge vertens cache-informasjon. Denne metoden kan fullstendig ignoreres.
| 
Publisert på 08.04.2019 11:01:48
|
|
|
|
