|
Nyligen påträffades en MySQL-server på grund av några speciella faktorer“FEL 1129 (00000): Värd 'xxx' blockeras på grund av många anslutningsfel. Avblockera med 'mysqladmin flush-hosts'”Efter att problemet var löst, i processen att lära mig mer om parametern max_connect_errors, förvirrade vissa motstridiga beskrivningar av olika nätverksdata mig lite (om detta fel, den huvudsakliga anledningen är att samma IP genererade för många avbrutna databasanslutningar (överstigande det maximala värdet max_connect_errors) på kort tid, och följande är en process där jag utforskar mina problem, analyserar problem och klargör tvivel. Först sökte jag på lite information på internet, många av dem svär att introducera att om antalet lösenordsinmatningsförsök överstiger max_connect_errors variabler, kommer MySQL att blockera denna klientinloggning, och sedan hittade jag den officiella informationen om introduktionen av max_connect_errors, som visas nedan, MySQL 5.6/5.7 är samma sak Om fler än så många successiva anslutningsförfrågningar från en värd avbryts utan att anslutningen lyckas, blockerar servern den värden från ytterligare anslutningar. Du kan avblockera blockerade värdar genom att tömma värdcachen. För att göra detta, utfärda en FLUSH HOSTS-sats eller kör ett mysqladmin flush-hosts-kommando. Om en anslutning upprättas framgångsrikt inom färre än max_connect_errors försök efter att en tidigare anslutning avbruts, rensas felräkningen för värden till noll. Men när en värd är blockerad är det enda sättet att avblockera värdcachen att rensa den. Standard är 100. Som visas ovan är översättningen ungefär följande: Om MySQL-servern tar emot på varandra följande förfrågningar från samma värd, och alla dessa på varandra följande förfrågningar avbryts utan att en anslutning lyckas upprättas, när det kumulativa värdet av dessa på varandra följande förfrågningar är större än det max_connect_errors satta värdet, kommer MySQL-servern att blockera alla efterföljande förfrågningar från denna värd. Jag tror att när du ser denna information i början, kommer du också att bli attackerad“Många på varandra följande anslutningsförfrågningar från en värd avbryts utan att en lyckad anslutning uppnås”Förvirrad, faktiskt beror detta på att databasanslutningen avbryts på grund av nätverksavvikelser. Jag sökte efter sådan information på internet: Det verkar råda förvirring kring den variabeln. Den blockerar egentligen inte värdar för upprepade ogiltiga lösenord utan för avbrutna anslutningar på grund av nätverksfel. Då kan vi experimentera och verifiera det själva för att ta reda på vilken som är korrekt. Skapa ett testkonto i MySQL-databasen och sedan sätter vi max_connect_errors variabeln till3. Sedan använder vi en annan testmaskin för att ansluta till MySQL-databasen med fel lösenord, som visas nedan, även om de tre tidigare felaktiga lösenorden matas in, stöter inte den fjärde inmatningen på ovanstående fel.Då kan du utesluta att denna variabel har något att göra med fel lösenordsinmatning. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 1045 (28000): Åtkomst nekad för användaren 'test'@'mytestlnx02' (använder lösenord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 1045 (28000): Åtkomst nekad för användaren 'test'@'mytestlnx02' (använder lösenord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 1045 (28000): Åtkomst nekad för användaren 'test'@'mytestlnx02' (använder lösenord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 1045 (28000): Åtkomst nekad för användaren 'test'@'mytestlnx02' (använder lösenord: JA) [root@mytestlnx02 tmp] # Faktum är att om en IP anger ett felaktigt lösenord, kommer MySQL att registrera det i host_cache-tabellen under performance_schema-databasen. Den registreras kumulativt i COUNT_AUTHENTICATION_ERRORS fält enligt följande:
Enligt officiell information betraktas host_cache område statistiskt som“Blockering”av anslutningsfel (bedömda baserat på max_connect_errors systemvariabler). Endast protokollhandskakningsfel räknas och används endast för autentiserade värdar (HOST_VALIDATED = JA). SUM_CONNECT_ERRORS Antalet anslutningsfel som anses vara "blockerande" (bedöms motmax_connect_errorssystemvariabel). Endast protokollhandskakningsfel räknas, och endast för värdar som klarat valideringen (HOST_VALIDATED = JA). MySQLKlienten måste initiera ett trefaldigt handshake-protokoll för att etablera en anslutning med databasen, under normala omständigheter är denna tid mycket kort, men när nätverksavvikelser, nätverkstidsavbrott och andra faktorer dyker upp, kommer det att göra att handshake-protokollet inte kan slutföras, MySQL har en parameter connect_timeout, det är dags för MySQL-serverprocessen mysqld att vänta på att anslutningen ska etableras, inom några sekunder. Om protokollhandslaget fortfarande inte är klart efter den connect_timeout tidsramen kommer MySQL-klienten att få ett undantag med ett undantagsmeddelande liknande följande: Tappade anslutningen till MySQL-servern vid 'XXX', systemfel: Errno, variabeln är som standard 10 sekunder:
Låt oss konstruera ett fall där databasanslutningen avbryts på grund av nätverkstimeout, vi använder netem- och tc-kommandona i Linux för att simulera fallet med nätverksöverföringsfördröjning i en komplex miljö, efter följande inställningar, vid denna tidpunkt från testservern till MySQL-servern, kommer det att vara en fördröjning 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 från 10.20.57.24: icmp_seq=1 ttl=62 time=0.251 ms 64 byte från 10.20.57.24: icmp_seq=2 ttl=62 time=0.330 ms 64 byte från 10.20.57.24: icmp_seq=3 ttl=62 time=0.362 ms 64 byte från 10.20.57.24: icmp_seq=4 ttl=62 time=0.316 ms 64 byte från 10.20.57.24: icmp_seq=5 ttl=62 tid=0,281 ms 64 byte från 10.20.57.24: icmp_seq=6 ttl=62 time=0.377 ms ^C --- 10.20.57.24 pingstatistik --- 6 paket skickade, 6 mottagna, 0% paketförlust, 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 från 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 byte från 10.20.57.24: icmp_seq=2 ttl=62 time=11000 ms 64 byte från 10.20.57.24: icmp_seq=3 ttl=62 time=11000 ms 64 byte från 10.20.57.24: icmp_seq=4 ttl=62 tid=11000 ms 64 byte från 10.20.57.24: icmp_seq=5 ttl=62 time=11000 ms 64 byte från 10.20.57.24: icmp_seq=6 ttl=62 time=11000 ms 64 byte från 10.20.57.24: icmp_seq=7 ttl=62 time=11000 ms
Vi ansluter till MySQL-databasen på testservern gettestlnx02 som visas nedan (observera att om du ansluter till denna server via ssh kommer det att vara ganska långsamt att köra gettestlnx02 just nu.) Självklart kan du också simulera nätverkslatens på MySQL-servern, eller så kan du göra både connect_timeout- och nätverkslatens mindre) [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 2013 (HY000): Tappade anslutningen till MySQL-servern vid 'läsauktoriseringspaket', systemfel: 0 [root@gettestlnx02 ~] # Som visas ovan, på grund av nätverksfördröjningen på mer än 10 sekunder, misslyckades anslutningen till MySQL, vid denna tidpunkt, när du frågar i host_cache-tabellen på MySQL-servern, då kommer du att se att SUM_CONNECT_ERRORS har blivit 1, och COUNT_HANDSHAKE_ERRORS har också ändrats1.
Sedan kastar vi så här tre gånger om och om igen, och du kommer att se att SUM_CONNECT_ERRORS blir 3, och COUNT_HANDSHAKE_ERRORS blir 3. Sedan använder vi netem- och tc-kommandon för att avbryta nätverkslatenssimuleringen på testservern, och går sedan till testanslutningen till MySQL-databasen, som visas i följande test: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Ange lösenord: FEL 1129 (HY000): Värd '192.168.27.180' blockeras på grund av många anslutningsfel; Avblockera med 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Vid denna tidpunkt kan den konstrueras“FEL 1129 (HY000): Värd '192.168.27.180' blockeras på grund av många anslutningsfel; Avblockera med 'mysqladmin flush-hosts'”Fel. lösning Löst FEL 1129 (00000): Värd 'xxx' är blockerad på grund av många anslutningsfel. Det finns många sätt att få felet Avblockera med 'mysqladmin flush-hosts', men vissa är tillfälliga. Den tillfälliga planen är att indikatorerna inte adresserar grundorsaken. Nyckeln är att rätta nätverksfel (som ofta kräver att man konsulterar nätverksadministratörer eller systemadministratörer) Lösning: 1, satte värdet på variabeln max_connection_errors till ett högre värde
Denna tillfälliga lösning är bara ett fördröjningsutlösande villkor för att IP:n ska förbjudas, och i komplexa fall eller hög samtidighet är det nödvändigt att sätta ett stort värde, annars triggas det lätt igen. Dessutom påverkar variabler endast den aktuella miljön och upphör om de startas om. 2: användningFlush-värdar MySQL> rensa värdar; Fråga OK, 0 rader påverkade (0,00 sek) mysql> välj * från performance_schema.host_cache; Tom mängd (0,00 sek) MySQL> Självklart kan du också använda kommandot mysqladmin flush-hosts för att rensa upp cacheinformationen för värdarna [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Ange lösenord: Så vad är värdcache? Den officiella introduktionen är följande: MySQL-servern underhåller en värdcache i minnet som innehåller information om klienter: IP-adress, värdnamn och felinformation. Servern använder denna cache för icke-lokala TCP-anslutningar. Den använder inte cachen för TCP-anslutningar som upprättas med en loopback-gränssnittsadress (127.0.0.1 eller ::1), eller för anslutningar som upprättas via en Unix-socketfil, namngiven pipe eller delad minne. Enkelt uttryckt håller MySQL-servern en cache i minnet som innehåller klientinformation: IP-adress, värdnamn, felmeddelande med mera. Servern cachar information om icke-lokal TCP-anslutning. Den cachar inte TCP-anslutningar som görs med loopback-gränssnittsadresser (127.0.0.1 eller::1), eller anslutningar som görs med Unix-socketfiler, namngivna pipelines eller delat minne. Värdcacheinformation kan sökas via tabellen host_cache i performance_schema databasen. 3: Sätt variabeln host_cache_size till0 Faktum är att jag skulle säga att detta är den mest opålitliga lösningen, bara för att få MySQL-servern att inte logga värdcacheinformationen. Denna metod kan helt ignoreras.
| 
Publicerad på 2019-04-08 11:01:48
|
|
|
|
