|
Kürzlich wurde aufgrund einiger besonderer Faktoren auf einen MySQL-Server gestoßen“FEHLER 1129 (00000): Host 'xxx' ist wegen vieler Verbindungsfehler blockiert. Entblocken mit 'mysqladmin flush-hosts'”Nachdem das Problem gelöst war und ich mehr über den Parameter max_connect_errors lernte, haben mich einige widersprüchliche Beschreibungen verschiedener Netzwerkdaten etwas verwirrt (bei diesem Fehler ist der Hauptgrund, dass dieselbe IP in kurzer Zeit zu viele unterbrochene Datenbankverbindungen erzeugte (die den maximalen Wert von max_connect_errors überschritt), und im Folgenden ist es ein Prozess, meine Probleme zu erforschen, Probleme zu analysieren und Zweifel zu klären. Zuerst habe ich einige Informationen im Internet gesucht, von denen viele schwören, einzuführen, dass MySQL diesen Client-Login blockiert, wenn die Anzahl der Passworteingabeversuche max_connect_errors Variablen übersteigt, und dann fand ich die offiziellen Informationen zur Einführung von max_connect_errors, wie unten gezeigt, MySQL 5.6/5.7 ist dasselbe Wenn mehr als dies mehrere aufeinanderfolgende Verbindungsanfragen eines Hosts ohne erfolgreiche Verbindung unterbrochen werden, blockiert der Server diesen Host von weiteren Verbindungen. Du kannst blockierte Hosts entblocken, indem du den Host-Cache leerst. Dazu geben Sie eine FLUSH HOSTS-Anweisung aus oder führen Sie einen mysqladmin flush-hosts-Befehl aus. Wird eine Verbindung innerhalb weniger als max_connect_errors Versuche nach der Unterbrechung einer vorherigen Verbindung erfolgreich hergestellt, wird die Fehleranzahl für den Host auf null gelöscht. Sobald ein Host jedoch blockiert ist, ist das Löschen des Host-Caches die einzige Möglichkeit, ihn zu entblocken. Der Standard ist 100. Wie oben gezeigt, sieht die Übersetzung ungefähr wie folgt aus: Wenn der MySQL-Server aufeinanderfolgende Anfragen vom selben Host erhält und alle diese aufeinanderfolgenden Anfragen unterbrochen werden, ohne eine Verbindung erfolgreich herzustellen, wird der MySQL-Server alle nachfolgenden Anfragen von diesem Host blockieren, wenn der kumulative Wert dieser aufeinanderfolgenden Anfragen größer ist als der max_connect_errors gesetzte Wert. Ich glaube, wenn Sie diese Informationen am Anfang sehen, werden Sie ebenfalls angegriffen“Viele aufeinanderfolgende Verbindungsanfragen eines Hosts werden ohne erfolgreiche Verbindung unterbrochen”Verwirrt, das liegt tatsächlich daran, dass die Datenbankverbindung aufgrund von Netzwerkanomalien abgebrochen wird. Ich habe im Internet nach solchen Informationen gesucht: Es scheint Verwirrung über diese Variable zu geben. Es blockiert Hosts nicht wirklich bei wiederholten ungültigen Passwörtern, sondern bei abgebrochenen Verbindungen aufgrund von Netzwerkfehlern. Nun, dann können wir selbst experimentieren und es überprüfen, um herauszufinden, welches richtig ist. Erstelle ein Testkonto in der MySQL-Datenbank und setzen dann die max_connect_errors-Variable auf3. Dann verwenden wir eine andere Testmaschine, um mit der MySQL-Datenbank mit dem falschen Passwort zu verbinden, wie unten gezeigt, und selbst wenn die vorherigen drei falschen Passwörter eingegeben wurden, stößt die vierte Eingabe nicht auf den oben genannten Fehler.Dann kannst du ausschließen, dass diese Variable etwas mit dem falschen Passworteintrag zu tun hat. [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 1045 (28000): Zugriff verweigert für Benutzer 'test'@'mytestlnx02' (Passwort verwendet: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 1045 (28000): Zugriff verweigert für Benutzer 'test'@'mytestlnx02' (Passwort verwendet: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 1045 (28000): Zugriff verweigert für Benutzer 'test'@'mytestlnx02' (Passwort verwendet: JA) [root@mytestlnx02 tmp]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 1045 (28000): Zugriff verweigert für Benutzer 'test'@'mytestlnx02' (Passwort verwendet: JA) [root@mytestlnx02 TMP] # Tatsächlich wird MySQL, wenn eine IP ein falsches Passwort eingibt, dies in der host_cache-Tabelle unter der performance_schema-Datenbank notieren. Sie wird kumulativ in COUNT_AUTHENTICATION_ERRORS Feldern wie folgt erfasst:
Laut offiziellen Informationen wird das host_cache Feld statistisch als folgt betrachtet als“Blockade”von Verbindungsfehlern (bewertet anhand max_connect_errors Systemvariablen). Nur Protokoll-Handshake-Fehler werden gezählt und nur für authentifizierte Hosts verwendet (HOST_VALIDATED = JA). SUM_CONNECT_ERRORS Die Anzahl der Verbindungsfehler, die als "blockierend" gelten (gemessen mit demmax_connect_errorsSystemvariable). Nur Protokoll-Handshake-Fehler werden gezählt, und nur für Hosts, die die Validierung bestanden haben (HOST_VALIDATED = JA). MySQLDer Client muss ein dreimalige Handshake-Protokoll initiieren, um eine Verbindung zur Datenbank herzustellen. Unter normalen Umständen ist diese Zeit sehr kurz, aber sobald die Netzwerkanomalie, der Netzwerk-Timeout und andere Faktoren auftreten, kann das Handshake-Protokoll nicht abgeschlossen werden. MySQL hat einen Parameter connect_timeout, es ist die Zeit, in der der MySQL-Server-Prozess mysqld auf die Verbindung in Sekunden warten muss. Wenn der Protokollhandshake nach dem connect_timeout Zeitrahmen immer noch nicht abgeschlossen ist, erhält der MySQL-Client eine Ausnahme mit einer Ausnahmemeldung ähnlich: Verbindung zum MySQL-Server bei 'XXX' verloren, Systemfehler: Errno, die Variable steht standardmäßig auf 10 Sekunden:
Nehmen wir einen Fall auf, in dem die Datenbankverbindung durch Netzwerkzeitabbruch unterbrochen wird. Wir verwenden die Befehle netem und tc in Linux, um den Fall der Netzwerkübertragungsverzögerung in einer komplexen Umgebung zu simulieren. Nach den folgenden Einstellungen, zu diesem Zeitpunkt vom Testserver zum Zugriff auf den MySQL-Server, gibt es eine Verzögerung von 11 Sekunden: [root@gettestlnx02 ~]# Ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) Bytes Daten. 64 Bytes von 10.20.57.24: icmp_seq=1 ttl=62 time=0,251 ms 64 Bytes vom 10.20.57.24: icmp_seq=2 ttl=62 time=0,330 ms 64 Bytes von 10.20.57.24: icmp_seq=3 ttl=62 time=0,362 ms 64 Bytes von 10.20.57.24: icmp_seq=4 ttl=62 time=0,316 ms 64 Bytes vom 10.20.57.24: icmp_seq=5 ttl=62 time=0,281 ms 64 Bytes vom 10.20.57.24: icmp_seq=6 ttl=62 time=0,377 ms ^C --- 10.20.57.24 Ping-Statistiken --- 6 gesendete Pakete, 6 empfangen, 0% Paketverlust, Zeit 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 Daten. 64 Bytes von 10.20.57.24: icmp_seq=1 ttl=62 time=11000 ms 64 Bytes vom 10.20.57.24: icmp_seq=2 ttl=62 time=11000 ms 64 Bytes vom 10.20.57.24: icmp_seq=3 ttl=62 time=11000 ms 64 Bytes vom 10.20.57.24: icmp_seq=4 ttl=62 time=11000 ms 64 Bytes von 10.20.57.24: icmp_seq=5 ttl=62 time=11000 ms 64 Bytes von 10.20.57.24: icmp_seq=6 ttl=62 time=11000 ms 64 Bytes vom 10.20.57.24: icmp_seq=7 ttl=62 time=11000 ms
Wir verbinden uns mit der MySQL-Datenbank auf dem Testserver gettestlnx02, wie unten gezeigt (beachten Sie, dass es derzeit ziemlich langsam ist, wenn Sie sich über SSH mit diesem Server verbinden). Natürlich kann man auch die Netzwerklatenz auf dem MySQL-Server simulieren oder sowohl die connect_timeout als auch die Netzwerklatenz verringern.) [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 2013 (HY000): Verbindung zum MySQL-Server bei 'Leseautorisierungspaket' verloren, Systemfehler: 0 [root@gettestlnx02 ~] # Wie oben gezeigt, ist aufgrund einer Netzwerkverzögerung von mehr als 10 Sekunden die Verbindung zu MySQL ausgebrochen. Wenn Sie die host_cache-Tabelle auf dem MySQL-Server abfragen, sehen Sie, dass die SUM_CONNECT_ERRORS auf 1 geworden ist und sich auch die COUNT_HANDSHAKE_ERRORS geändert hat1.
Dann werfen wir so dreimal wiederholt, und du wirst sehen, dass der SUM_CONNECT_ERRORS zu 3 und der COUNT_HANDSHAKE_ERRORS zu 3 wird. Dann verwenden wir netem- und tc-Befehle, um die Netzwerklatenzsimulation auf dem Testserver abzubrechen, und gehen dann zur Testverbindung zur MySQL-Datenbank, wie im folgenden Test gezeigt: [root@gettestlnx02 ~]# tc qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# MySQL -h10.20.57.24 -utest -p Passwort eingeben: FEHLER 1129 (HY000): Host '192.168.27.180' ist wegen vieler Verbindungsfehler blockiert; Entblocken mit 'mysqladmin flush-hosts' [root@gettestlnx02 ~] #
Zu diesem Zeitpunkt kann es gebaut werden“FEHLER 1129 (HY000): Host '192.168.27.180' ist wegen vieler Verbindungsfehler blockiert; Entblocken mit 'mysqladmin flush-hosts'”Falsch. Lösung FEHLER 1129 (00000) behoben: Host 'xxx' ist wegen vieler Verbindungsfehler blockiert. Es gibt viele Möglichkeiten, den Fehler "Entblocken" mit 'mysqladmin flush-hosts' zu erhalten, aber einige sind temporär. Der temporäre Plan ist, dass die Indikatoren die Ursache nicht adressieren. Der Schlüssel ist, Netzwerkfehler zu beheben (die oft die Rücksprache mit Netzwerk- oder Systemadministratoren erfordern) Workaround: 1, setze den Wert der Variablen max_connection_errors auf einen größeren Wert
Diese temporäre Lösung ist lediglich eine Verzögerungsbedingung, damit die IP verboten wird, und in komplexen Fällen oder hoher Nebenläufigkeit ist es notwendig, einen hohen Wert zu setzen, sonst wird er leicht erneut ausgelöst. Außerdem wirken sich Variablen nur auf die aktuelle Umgebung aus und verfallen, wenn sie neu gestartet werden. 2: VerwendungFlush-Hosts MySQL> Hosts flushen; Abfrage OK, 0 betroffene Zeilen (0,00 Sekunden) MySQL> wählen * aus performance_schema.host_cache; Leere Menge (0,00 Sek.) MySQL> Natürlich kannst du auch den Befehl mysqladmin flush-hosts verwenden, um die Cache-Informationen des Hosts zu bereinigen [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Passwort eingeben: Was ist also ein Host-Cache? Die offizielle Einführung lautet wie folgt: Der MySQL-Server verwaltet einen Host-Cache im Speicher, der Informationen über Clients enthält: IP-Adresse, Hostname und Fehlerinformationen. Der Server nutzt diesen Cache für nicht-lokale TCP-Verbindungen. Er verwendet den Cache nicht für TCP-Verbindungen, die über eine Loopback-Schnittstellenadresse (127.0.0.1 oder ::1) hergestellt wurden, oder für Verbindungen, die über eine Unix-Socket-Datei, eine genannte Pipe oder eine geteilte Datei hergestellt werden Erinnerung. Einfach ausgedrückt verwaltet der MySQL-Server einen Cache im Speicher, der Client-Informationen enthält: IP-Adresse, Hostname, Fehlermeldung usw. Der Server speichert nicht-lokale TCP-Verbindungsinformationen. Es speichert keine TCP-Verbindungen, die mit Loopback-Schnittstellenadressen (127.0.0.1 oder::1) hergestellt wurden, oder Verbindungen mit Unix-Socket-Dateien, benannten Pipelines oder gemeinsamem Speicher. Host-Cache-Informationen können über die host_cache-Tabelle in der performance_schema-Datenbank abgefragt werden. 3: Setze die Variable host_cache_size auf0 Tatsächlich würde ich sagen, dass dies die unzuverlässigste Lösung ist, nur um zu verhindern, dass der MySQL-Server die Host-Cache-Informationen protokolliert. Diese Methode kann völlig ignoriert werden.
| 
Veröffentlicht am 08.04.2019 11:01:48
|
|
|
|
