|
Onlangs werd een MySQL-server tegengekomen vanwege enkele bijzondere factoren“FOUT 1129 (00000): Host 'xxx' is geblokkeerd vanwege veel verbindingsfouten. Deblokkeren met 'mysqladmin flush-hosts'”Nadat het probleem was opgelost, en ik meer leerde over de parameter max_connect_errors, verwarden enkele tegenstrijdige beschrijvingen van verschillende netwerkgegevens me een beetje (over deze fout is de belangrijkste reden dat hetzelfde IP in korte tijd te veel onderbroken databaseverbindingen genereerde (die de maximale waarde van max_connect_errors overschreed), en het volgende is een proces van het onderzoeken van mijn problemen, het analyseren van problemen en het verduidelijken van twijfels. Allereerst heb ik wat informatie op internet opgezocht, waarvan velen zweren te introduceren dat als het aantal wachtwoordinvoerpogingen max_connect_errors variabelen overschrijdt, MySQL deze clientlogin blokkeert, en toen vond ik de officiële informatie over de introductie van max_connect_errors, zoals hieronder getoond, MySQL 5.6/5.7 hetzelfde is Als meer dan dit aantal opeenvolgende verbindingsverzoeken van een host wordt onderbroken zonder een succesvolle verbinding, blokkeert de server die host voor verdere verbindingen. Je kunt geblokkeerde hosts deblokkeren door de hostcache te leegmaken. Om dit te doen, voer je een FLUSH HOSTS-instructie uit of voer je een mysqladmin flush-hosts commando uit. Als een verbinding binnen minder dan max_connect_errors pogingen na het onderbreken van een vorige verbinding succesvol tot stand is gekomen, wordt het foutenaantal voor de host op nul geveegd. Echter, zodra een host geblokkeerd is, is het leegmaken van de hostcache de enige manier om deze te deblokkeren. De standaard is 100. Zoals hierboven getoond, is de vertaling ongeveer als volgt: Als de MySQL-server opeenvolgende verzoeken van dezelfde host ontvangt, en al deze opeenvolgende verzoeken worden onderbroken zonder dat er een verbinding succesvol is tot stand gebracht, zal de MySQL-server alle volgende verzoeken blokkeren, wanneer de cumulatieve waarde van deze opeenvolgende verzoeken groter is dan de max_connect_errors gestelde waarde. Ik geloof dat wanneer je deze informatie aan het begin ziet, je ook aangevallen zult worden“Veel opeenvolgende verbindingsverzoeken van een host worden onderbroken zonder een succesvolle verbinding”Verward, dit komt eigenlijk doordat de databaseverbinding wordt afgebroken vanwege netwerkafwijkingen. Ik heb op internet naar dergelijke informatie gezocht: Er lijkt verwarring te zijn over die variabele. Het blokkeert hosts niet echt voor herhaalde ongeldige wachtwoorden, maar voor afgebroken verbindingen door netwerkfouten. Dan kunnen we zelf experimenteren en verifiëren welke klopt. Maak een testaccount aan in de MySQL-database, en dan zetten we de variabele max_connect_errors op3. Vervolgens gebruiken we een andere testmachine om verbinding te maken met de MySQL-database met het verkeerde wachtwoord, zoals hieronder getoond; zelfs als de vorige drie verkeerde wachtwoorden zijn ingevoerd, ondervindt de vierde invoer de bovenstaande fout niet.Dan kun je uitsluiten dat deze variabele iets te maken heeft met de verkeerde wachtwoordinvoer. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 1045 (28000): Toegang geweigerd voor gebruiker 'test'@'mytestlnx02' (met wachtwoord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 1045 (28000): Toegang geweigerd voor gebruiker 'test'@'mytestlnx02' (met wachtwoord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 1045 (28000): Toegang geweigerd voor gebruiker 'test'@'mytestlnx02' (met wachtwoord: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 1045 (28000): Toegang geweigerd voor gebruiker 'test'@'mytestlnx02' (met wachtwoord: JA) [root@mytestlnx02 tmp] # Als een IP een verkeerd wachtwoord invoert, zal MySQL dit registreren in de host_cache-tabel onder de performance_schema database. Het wordt cumulatief geregistreerd in COUNT_AUTHENTICATION_ERRORS velden als volgt:
Volgens officiële informatie wordt het host_cache vakgebied statistisch gezien als volgt beschouwd“Verstopping”van verbindingsfouten (beoordeeld op basis van max_connect_errors systeemvariabelen). Alleen protocolhandshakefouten worden geteld en worden alleen gebruikt voor geauthenticeerde hosts (HOST_VALIDATED = JA). SUM_CONNECT_ERRORS Het aantal verbindingsfouten dat als "blokkerend" wordt beschouwd (gemeten aan de hand van demax_connect_errorssysteemvariabele). Alleen protocolhandshakefouten worden geteld, en alleen voor hosts die validatie hebben doorstaan (HOST_VALIDATED = JA). MySQLDe client moet een drievoudig handshakeprotocol initiëren om een verbinding met de database te maken; normaal gesproken is deze tijd zeer kort, maar zodra de netwerkafwijking, netwerktimeout en andere factoren optreden, kan het handshakeprotocol niet worden voltooid. MySQL heeft een parameter connect_timeout, het is de tijd voor het MySQL-serverproces mysqld om te wachten tot de verbinding tot stand komt, binnen enkele seconden. Als de protocolhandshake na de connect_timeout tijdsperiode nog steeds niet is voltooid, ontvangt de MySQL-client een uitzondering met een uitzonderingsbericht vergelijkbaar met: Verbinding met MySQL-server verloren bij 'XXX', systeemfout: errno, de variabele is standaard 10 seconden:
Laten we een geval construeren waarin de databaseverbinding wordt onderbroken door netwerktimeout; we gebruiken de netem- en tc-commando's in Linux om het geval van netwerktransmissievertraging in een complexe omgeving te simuleren; na de volgende instellingen, vanaf de testserver naar toegang tot de MySQL-server, zal er een vertraging van 11 seconden zijn: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bytes aan data. 64 bytes van 10.20.57.24: icmp_seq=1 ttl=62 time=0.251 ms 64 bytes van 10.20.57.24: icmp_seq=2 ttl=62 time=0.330 ms 64 bytes van 10.20.57.24: icmp_seq=3 ttl=62 time=0.362 ms 64 bytes van 10.20.57.24: icmp_seq=4 ttl=62 tijd=0,316 ms 64 bytes van 10.20.57.24: icmp_seq=5 ttl=62 tijd=0,281 ms 64 bytes van 10.20.57.24: icmp_seq=6 ttl=62 tijd=0,377 ms ^C --- 10.20.57.24 pingstatistieken --- 6 pakketten verzonden, 6 ontvangen, 0% pakketverlies, tijd 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 aan data. 64 bytes van 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 bytes van 10.20.57.24: icmp_seq=2 ttl=62 time=11000 ms 64 bytes van 10.20.57.24: icmp_seq=3 ttl=62 tijd=11000 ms 64 bytes van 10.20.57.24: icmp_seq=4 ttl=62 time=11000 ms 64 bytes van 10.20.57.24: icmp_seq=5 ttl=62 time=11000 ms 64 bytes van 10.20.57.24: icmp_seq=6 ttl=62 time=11000 ms 64 bytes van 10.20.57.24: icmp_seq=7 ttl=62 time=11000 ms
We verbinden met de MySQL-database op de testserver gettestlnx02 zoals hieronder weergegeven (let op: als je via ssh verbinding maakt met deze server, zal het op dit moment vrij traag zijn om op gettestlnx02 te werken). Natuurlijk kun je ook netwerklatentie simuleren op de MySQL-server, of je kunt zowel connect_timeout als netwerklatentie kleiner maken) [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 2013 (HY000): Verbinding met MySQL-server verloren bij 'reading authorization packet', systeemfout: 0 [root@gettestlnx02 ~] # Zoals hierboven getoond, door een netwerkvertraging van meer dan 10 seconden, faalde de verbinding met MySQL; op dit moment, wanneer je de host_cache-tabel op de MySQL-server raadpleegt, zie je dat de SUM_CONNECT_ERRORS 1 is geworden, en dat de COUNT_HANDSHAKE_ERRORS ook is veranderd1.
Dan gooien we zo drie keer herhaaldelijk, en je zult zien dat de SUM_CONNECT_ERRORS 3 wordt, en de COUNT_HANDSHAKE_ERRORS 3. Vervolgens gebruiken we netem- en tc-commando's om de netwerklatentiesimulatie op de testserver te annuleren, en gaan we vervolgens naar de testverbinding met de MySQL-database, zoals te zien is in de volgende test: [root@gettestlnx02 ~]# TC Qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Voer wachtwoord in: FOUT 1129 (HY000): Host '192.168.27.180' is geblokkeerd vanwege veel verbindingsfouten; Deblokkeren met 'MySQLADMIN flush-hosts' [root@gettestlnx02 ~] #
Op dit moment kan het worden gebouwd“FOUT 1129 (HY000): Host '192.168.27.180' is geblokkeerd vanwege veel verbindingsfouten; Deblokkeren met 'MySQLADMIN flush-hosts'”Fout. oplossing FOUT 1129 (00000) opgelost: Host 'xxx' is geblokkeerd vanwege veel verbindingsfouten. Er zijn veel manieren om de foutmelding Unblock te krijgen met 'mysqladmin flush-hosts', maar sommige zijn tijdelijk. Het tijdelijke plan is dat de indicatoren de onderliggende oorzaak niet aanpakken. De sleutel is het oplossen van netwerkfouten (die vaak het raadplegen van netwerkbeheerders of systeembeheerders vereisen) Oplossing: 1, zet de waarde van de variabele max_connection_errors op een hogere waarde
Deze tijdelijke oplossing is slechts een vertragingsvoorwaarde om het IP te verbieden, en in complexe gevallen of hoge gelijktijdigheid is het noodzakelijk een hoge waarde in te stellen, anders wordt het gemakkelijk opnieuw geactiveerd. Daarnaast hebben variabelen alleen invloed op de huidige omgeving en vervallen ze als ze opnieuw worden opgestart. 2: gebruikFlush hosts MySQL> hosts; Query OK, 0 rijen beïnvloed (0,00 sec) mysql> selecteer * uit performance_schema.host_cache; Lege verzameling (0,00 sec) MySQL> Natuurlijk kun je ook het mysqladmin flush-hosts commando gebruiken om de cache-informatie van de host op te schonen [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Voer wachtwoord in: Wat is dan een hostcache? De officiële introductie is als volgt: De MySQL-server onderhoudt een hostcache in het geheugen die informatie over clients bevat: IP-adres, hostnaam en foutinformatie. De server gebruikt deze cache voor niet-lokale TCP-verbindingen. Het gebruikt de cache niet voor TCP-verbindingen die zijn tot stand gebracht met een loopback-interfaceadres (127.0.0.1 of ::1), of voor verbindingen die worden gemaakt met een Unix-socketbestand, named pipe of gedeeld herinnering. In eenvoudige termen onderhoudt de MySQL-server een cache in het geheugen met clientinformatie: IP-adres, hostnaam, foutmelding, enzovoort. De server cachet niet-lokale TCP-verbindingsinformatie. Het cachet geen TCP-verbindingen die zijn gemaakt met loopback-interfaceadressen (127.0.0.1 of::1), of verbindingen gemaakt met Unix-socketbestanden, benoemde pijplijnen of gedeeld geheugen. Hostcache-informatie kan worden opgevraagd via de host_cache-tabel in de performance_schema database. 3: Stel de variabele host_cache_size in op0 Sterker nog, ik zou zeggen dat dit de meest onbetrouwbare oplossing is, alleen al om te voorkomen dat de MySQL-server de hostcache-informatie niet registreert. Deze methode kan volledig genegeerd worden.
| 
Geplaatst op 08-04-2019 11:01:48
|
|
|
|
