|
For nylig blev en MySQL-server opdaget på grund af nogle særlige faktorer“FEJL 1129 (00000): Vært 'xxx' er blokeret på grund af mange forbindelsesfejl. Afblok med 'mysqladmin flush-hosts'”Efter at problemet var løst, i processen med at lære mere om parameteren max_connect_errors, forvirrede nogle modstridende beskrivelser af forskellige netværksdata mig lidt (om denne fejl er den væsentlige grund, at den samme IP genererede for mange afbrudte databaseforbindelser (over den maksimale værdi af max_connect_errors) på kort tid, og det følgende er en proces med at udforske mine problemer, analysere problemer og afklare tvivl. Først søgte jeg noget information på internettet, hvoraf mange sværger at introducere, at hvis antallet af adgangskodeforsøg overstiger max_connect_errors variable, vil MySQL blokere denne klientlogin, og så fandt jeg de officielle oplysninger om introduktionen af max_connect_errors, som vist nedenfor, MySQL 5.6/5.7 er det samme Hvis flere på hinanden følgende forbindelsesforespørgsler fra en vært afbrydes uden en succesfuld forbindelse, blokerer serveren den vært for yderligere forbindelser. Du kan fjerne blokeringen af blokerede hosts ved at tømme hostens cache. For at gøre dette skal du udstede en FLUSH HOSTS-sætning eller udføre en mysqladmin flush-hosts kommando. Hvis en forbindelse etableres med succes inden for færre end max_connect_errors forsøg efter, at en tidligere forbindelse blev afbrudt, slettes fejltællingen for værten til nul. Men når en vært er blokeret, er det kun at tømme værtscachen for at fjerne blokeringen. Standardindstillingen er 100. Som vist ovenfor er oversættelsen omtrent som følger: Hvis MySQL-serveren modtager på hinanden følgende anmodninger fra samme vært, og alle disse på hinanden følgende anmodninger afbrydes uden at etablere en forbindelse, vil MySQL-serveren blokere alle efterfølgende anmodninger, når den samlede værdi af disse på hinanden følgende anmodninger er større end den max_connect_errors satte værdi. Jeg tror, at når du ser denne information i starten, vil du også blive angrebet“Mange efterfølgende forbindelsesforespørgsler fra en vært afbrydes uden en vellykket forbindelse”Forvirret skyldes det faktisk, at databaseforbindelsen afbrydes på grund af netværksforstyrrelser. Jeg søgte efter sådan information på internettet: Der ser ud til at være forvirring omkring den variabel. Den blokerer ikke rigtig værter for gentagne ugyldige adgangskoder, men for afbrudte forbindelser på grund af netværksfejl. Så kan vi eksperimentere og selv verificere det for at finde ud af, hvilken der er korrekt. Opret en testkonto i MySQL-databasen, og så sætter vi max_connect_errors-variablen til3. Derefter bruger vi en anden testmaskine til at forbinde til MySQL-databasen med den forkerte adgangskode, som vist nedenfor, selv hvis de tre foregående forkerte adgangskoder indtastes, støder det fjerde input ikke på ovenstående fejl.Så kan du udelukke, at denne variabel har noget at gøre med den forkerte adgangskodeindtastning. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Indtast adgangskode: FEJL 1045 (28000): Adgang nægtet for brugeren 'test'@'mytestlnx02' (bruger adgangskode: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Indtast adgangskode: FEJL 1045 (28000): Adgang nægtet for brugeren 'test'@'mytestlnx02' (bruger adgangskode: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Indtast adgangskode: FEJL 1045 (28000): Adgang nægtet for brugeren 'test'@'mytestlnx02' (bruger adgangskode: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Indtast adgangskode: FEJL 1045 (28000): Adgang nægtet for brugeren 'test'@'mytestlnx02' (bruger adgangskode: JA) [root@mytestlnx02 tmp] # Faktisk, hvis en IP indtaster en forkert adgangskode, vil MySQL registrere det i host_cache tabellen under performance_schema-databasen. Den registreres kumulativt i COUNT_AUTHENTICATION_ERRORS felter som følger:
Ifølge officielle oplysninger betragtes det host_cache felt statistisk som“Blokering”af forbindelsesfejl (vurderet ud fra max_connect_errors systemvariabler). Kun protokoller-håndtryksfejl tælles og bruges kun til autentificerede værter (HOST_VALIDATED = JA). SUM_CONNECT_ERRORS Antallet af forbindelsesfejl, der betragtes som "blokering" (vurderet modmax_connect_errorssystemvariabel). Kun protokolhåndtryksfejl tælles, og kun for værter, der bestod valideringen (HOST_VALIDATED = JA). MySQLKlienten skal igangsætte en tre-gangs håndtryksprotokol for at etablere en forbindelse til databasen; under normale omstændigheder er denne tid meget kort, men når netværksabnormiteten, netværkstimeout og andre faktorer opstår, vil det gøre, at håndtryksprotokollen ikke kan fuldføres. MySQL har en parameter connect_timeout, det er tid for MySQL-serverprocessen mysqld til at vente på, at forbindelsen bliver etableret, på få sekunder. Hvis protokollens håndtryk stadig ikke er færdiggjort efter den connect_timeout tidsramme, vil MySQL-klienten modtage en undtagelse med en undtagelsesmeddelelse svarende: Mistede forbindelsen til MySQL-serveren ved 'XXX', systemfejl: Errno, variabelen er som standard 10 sekunder:
Lad os konstruere et tilfælde, hvor databaseforbindelsen afbrydes på grund af netværkstimeout, vi bruger netem- og tc-kommandoerne i Linux til at simulere tilfælde af netværksoverførselsforsinkelse i et komplekst miljø, efter følgende indstillinger, på dette tidspunkt fra testserveren til adgang til MySQL-serveren, vil der være en forsinkelse på 11 sekunder: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes data. 64 bytes fra 10.20.57.24: icmp_seq=1 ttl=62 time=0.251 ms 64 bytes 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 bytes fra 10.20.57.24: icmp_seq=4 ttl=62 time=0.316 ms 64 bytes fra 10.20.57.24: icmp_seq=5 ttl=62 time=0.281 ms 64 bytes fra 10.20.57.24: icmp_seq=6 ttl=62 time=0.377 ms ^C --- 10.20.57.24 ping-statistik --- 6 pakker sendt, 6 modtaget, 0% pakketab, 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 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes data. 64 bytes fra 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=2 ttl=62 tid=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=3 ttl=62 time=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=4 ttl=62 time=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=5 ttl=62 tid=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=6 ttl=62 tid=11000 ms 64 bytes fra 10.20.57.24: icmp_seq=7 ttl=62 time=11000 ms
Vi forbinder til MySQL-databasen på testserveren gettestlnx02 som vist nedenfor (bemærk, at hvis du forbinder til denne server via ssh, vil det være ret langsomt at køre på gettestlnx02 på nuværende tidspunkt). Selvfølgelig kan du også simulere netværkslatens på MySQL-serveren, eller du kan gøre både connect_timeout- og netværkslatens mindre) [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Indtast adgangskode: FEJL 2013 (HY000): Mistede forbindelsen til MySQL-serveren ved 'læseautorisationspakke', systemfejl: 0 [root@gettestlnx02 ~] # Som vist ovenfor, på grund af netværksforsinkelsen på mere end 10 sekunder, mislykkedes forbindelsen til MySQL; på dette tidspunkt, når du forespørger host_cache-tabellen på MySQL-serveren, vil du se, at SUM_CONNECT_ERRORS er blevet 1, og COUNT_HANDSHAKE_ERRORS er også ændret1.
Så kaster vi sådan tre gange gentagne gange, og du vil se, at SUM_CONNECT_ERRORS bliver til 3, og COUNT_HANDSHAKE_ERRORS bliver til 3. Derefter bruger vi netem- og tc-kommandoer til at annullere netværkslatenssimuleringen på testserveren, og går derefter til testforbindelsen 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 Indtast adgangskode: FEJL 1129 (HY000): Værten '192.168.27.180' er blokeret på grund af mange forbindelsesfejl; Ophæv blokeringen med 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
På nuværende tidspunkt kan den bygges“FEJL 1129 (HY000): Værten '192.168.27.180' er blokeret på grund af mange forbindelsesfejl; Ophæv blokeringen med 'mysqladmin flush-hosts'”Forkert. opløsning Løst FEJL 1129 (00000): Vært 'xxx' er blokeret på grund af mange forbindelsesfejl. Der er mange måder at få fejlen Unblock med 'mysqladmin flush-hosts' på, men nogle er midlertidige. Den midlertidige plan er, at indikatorerne ikke adresserer den egentlige årsag. Nøglen er at rette netværksfejl (som ofte kræver konsultation med netværksadministratorer eller systemadministratorer) Løsning: 1, sæt værdien af variablen max_connection_errors til en højere værdi
Denne midlertidige løsning er blot en forsinkelsesudløsende betingelse for, at IP'en kan forbydes, og i komplekse tilfælde eller høj samtidighed er det nødvendigt at sætte en stor værdi, ellers vil den let blive udløst igen. Derudover påvirker variabler kun det nuværende miljø og udløber, hvis de genstartes. 2: brugFlush Hosts MySQL> Flush Hosts; Forespørgsel OK, 0 rækker påvirket (0,00 sek) MySQL> vælg * fra performance_schema.host_cache; Tom mængde (0,00 sek) MySQL> Selvfølgelig kan du også bruge kommandoen mysqladmin flush-hosts til at rydde op i hostens cache-information [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Indtast adgangskode: Så hvad er værtscache? Den officielle introduktion er som følger: MySQL-serveren vedligeholder en værtscache i hukommelsen, som indeholder information om klienter: IP-adresse, værtsnavn og fejlinformation. Serveren bruger denne cache til ikke-lokale TCP-forbindelser. Den bruger ikke cachen til TCP-forbindelser, der etableres via en loopback-interfaceadresse (127.0.0.1 eller ::1), eller til forbindelser etableret via en Unix-socketfil, navngivet pipe eller delt Hukommelse. Kort sagt vedligeholder MySQL-serveren en cache i hukommelsen, der indeholder klientinformation: IP-adresse, værtsnavn, fejlmeddelelse osv. Serveren cacher ikke-lokal TCP-forbindelsesinformation. Den cacher ikke TCP-forbindelser lavet via loopback-interfaceadresser (127.0.0.1 eller::1), eller forbindelser lavet via Unix-socketfiler, navngivne pipelines eller delt hukommelse. Værtscache-information kan forespørges gennem host_cache-tabellen i performance_schema-databasen. 3: Sæt variablen host_cache_size til0 Faktisk vil jeg sige, at dette er den mest upålidelige løsning, bare for at få MySQL-serveren til ikke at logge værtscache-informationen. Denne metode kan fuldstændig ignoreres.
| 
Opslået på 08/04/2019 11.01.48
|
|
|
|
