Analyse des MySQL-Warnprotokolls zu abgebrochenen Verbindungen

Vorwort:

Manchmal wird die mit MySQL verbundene Sitzung abnormal beendet und im Fehlerprotokoll wird ein Alarm des Typs „Beim Lesen der Kommunikationspakete ist ein Fehler aufgetreten“ angezeigt. In diesem Artikel besprechen wir die möglichen Ursachen dieses Fehlers und wie man ihn vermeidet.

1. Statusvariablen Aborted_clients und Aborted_connects

Lassen Sie uns zunächst die Bedeutung der beiden Statusvariablen Aborted_clients und Aborted_connects verstehen. Wenn eine Sitzung abnormal beendet wird, ändern sich diese beiden Statuswerte. Laut der offiziellen Dokumentation lautet die Zusammenfassung wie folgt:

Mögliche Gründe für den Anstieg der Statusvariable „Aborted_connects“:

1. Der Client hat versucht, auf eine Datenbank zuzugreifen, verfügte jedoch nicht über die Berechtigung zum Zugriff auf die Datenbank.
2. Der Client hat ein falsches Passwort verwendet.
3. Das Verbindungspaket enthält nicht die richtigen Informationen.
4. Das Abrufen eines Verbindungspakets hat länger als connect_timeout Sekunden gedauert.

Mögliche Gründe für den Anstieg der Statusvariable „Aborted_clients“:

1. Das Client-Programm hat vor dem Beenden mysql_close() nicht aufgerufen.
2. Der Client schläft länger als die durch die Parameter wait_timeout oder interactive_timeout angegebene Sekundenanzahl.
3. Das Client-Programm wurde während der Datenübertragung plötzlich beendet.

Einfach ausgedrückt: Wenn die Verbindung der Datenbanksitzung zur Datenbank nicht normal hergestellt werden kann, erhöht sich die Variable „Aborted_connects“. Die Datenbanksitzung wurde normal mit der Datenbank verbunden, konnte jedoch nicht normal beendet werden, was zu einer Erhöhung der Variable „Aborted_clients“ führt.

2. Beim Lesen der Kommunikationspakete ist ein Fehler aufgetreten. Ursachenanalyse

Welche Situation führt dazu, dass im Fehlerprotokoll ein Alarm ähnlich dem folgenden angezeigt wird: „Abgebrochene Verbindung xxxx zu db: ‚db‘ Benutzer: ‚dbuser‘ Host: ‚Hostname‘ (Beim Lesen der Kommunikationspakete ist ein Fehler aufgetreten)“? Als Nächstes führen wir basierend auf den oben genannten möglichen Gründen einige spezifische Tests durch. Achten Sie auf die Änderungen der Statusvariablen Aborted_clients und Aborted_connects sowie auf die Fehlerprotokolleinträge bei jedem Test.

• Test 1: Falsches Passwort, falscher Benutzer

1. Überprüfen Sie den Wert der Statusvariablen, bevor Sie MySQL testen. Zeigen Sie einen globalen Status wie „abort%“ an. +------------------+-------+| Variablenname | Wert |+------------------+-------+| Abgebrochene Clients | 0 || Abgebrochene Verbindungen | 0 |+------------------+-------+
2. Testvorgang# mysql -uroot -pwrongpassmysql: [Warnung] Die Verwendung eines Passworts auf der Kommandozeilenschnittstelle kann unsicher sein.FEHLER 1045 (28000): Zugriff verweigert für Benutzer ‚root‘@‚localhost‘ (mit Passwort: JA)# mysql -uroot1 -pwrongpassmysql: [Warnung] Die Verwendung eines Passworts auf der Kommandozeilenschnittstelle kann unsicher sein.FEHLER 1045 (28000): Zugriff verweigert für Benutzer ‚root1‘@‚localhost‘ (mit Passwort: JA)
3. Statusänderungen und Fehlerprotokoll anzeigenmysql> globalen Status wie „abort%“ anzeigen;+------------------+-------+| Variablenname | Wert |+------------------+-------+| Aborted_clients | 0 || Aborted_connects | 2 |+------------------+-------+Fehlerprotokolleintrag:2020-03-16T17:58:35.318819+08:00 6 [Hinweis] Zugriff verweigert für Benutzer „root“@„localhost“ (mit Kennwort: JA)2020-03-16T17:59:04.153753+08:00 7 [Hinweis] Zugriff verweigert für Benutzer „root1“@„localhost“ (mit Kennwort: JA)
Ergebnis: Aborted_connects hat ein Fehlerprotokoll, aber keine mit abgebrochenen Verbindungen zusammenhängenden Datensätze.

• Test 2: Ruhezustand-Timeout oder manuelle Sitzungsbeendigung

1. Überprüfen Sie den Wert der Statusvariablen, bevor Sie MySQL testen. Zeigen Sie einen globalen Status wie „abort%“ an. +------------------+----------+| Variablenname | Wert |+------------------+-------+| Aborted_clients | 0 || Aborted_connects | 2 |+------------------+-------+
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
3. Überprüfen Sie Statusänderungen und Fehlerprotokollemysql> zeigt globalen Status wie „abort%“ an;+------------------+-------+| Variablenname | Wert |+------------------+-------+| Aborted_clients | 1 || Aborted_connects | 2 |+------------------+-------+
Ergebnis: Aborted_clients wird hinzugefügt, aber es gibt keinen Eintrag im Fehlerprotokoll. Ebenso wird Aborted_clients nach Ablauf der Ruhezeit hinzugefügt, aber es gibt einen Eintrag über eine abgebrochene Verbindung im Fehlerprotokoll.

Ein abnormales Beenden einer Sitzung führt normalerweise zu einem Alarm „Verbindung abgebrochen“. Das heißt, wir können durch die Änderung der Statusvariable „Aborted_clients“ erkennen, ob eine abnormale Sitzung vorliegt. Dann ist der Grund für den Alarm „Beim Lesen der Kommunikationspakete ist ein Fehler aufgetreten“ und ähnliche Alarme sehr klar. Nach Rücksprache mit den relevanten Informationen werden die möglichen Gründe für den Alarm „Verbindung abgebrochen“ wie folgt zusammengefasst:

1. Die Sitzungsverbindung wurde nicht ordnungsgemäß geschlossen und das Programm hat mysql_close() nicht aufgerufen.
2. Ruhen Sie für eine Anzahl von Sekunden länger als die Parameter wait_timeout oder interactive_timeout.
3. Die Größe des Abfragedatenpakets überschreitet den Wert „max_allowed_packet“, wodurch die Verbindung unterbrochen wird.
4. Andere Netzwerk- oder Hardwareprobleme.
   

3. Problemvermeidung und Zusammenfassung

Tatsächlich sind Verbindungsabbruchsalarme schwer zu vermeiden. Im Fehlerprotokoll wird eine kleine Menge an Verbindungsabbruchsinformationen enthalten sein, die ignoriert werden können. Wenn jedoch in Ihrem Fehlerprotokoll häufig Verbindungsabbruchsalarme auftreten, sollten Sie darauf achten, da dies größere Auswirkungen auf Ihr Unternehmen haben kann. Hier sind einige Vorschläge, wie Sie Fehler vermeiden können. Ich hoffe, sie sind hilfreich für Sie.

1. Es wird empfohlen, dass die Anwendungslogik nach Abschluss des Geschäftsvorgangs die Verbindung ordnungsgemäß schließt und die lange Verbindung durch eine kurze Verbindung ersetzt.
2. Stellen Sie sicher, dass der Wert von max_allowed_packet hoch genug ist und dass der Client keine Meldung „Paket zu groß“ erhält.
3. Stellen Sie sicher, dass die Client-Anwendung die Verbindung nicht abbricht. Wenn PHP beispielsweise max_execution_time auf 5 Sekunden eingestellt hat, hilft eine Erhöhung von connect_timeout nicht, da PHP das Skript beendet. Andere Programmiersprachen und Umgebungen verfügen über ähnliche Sicherheitsoptionen.
4. Stellen Sie sicher, dass die Transaktionen (Beginn und Commit) korrekt ausgeführt werden, um sicherzustellen, dass die Verbindungen nach Abschluss der Anwendung in einem sauberen Zustand zurückbleiben.
5. Überprüft, ob „Skip-Name-Resolve“ aktiviert ist. Dadurch wird überprüft, ob Hosts basierend auf ihren IP-Adressen statt ihren Hostnamen authentifiziert werden.
6. Versuchen Sie, die MySQL-Werte net_read_timeout und net_write_timeout zu erhöhen, um zu sehen, ob dadurch die Anzahl der Fehler verringert wird.

Oben finden Sie eine detaillierte Analyse des Alarmprotokolls für abgebrochene MySQL-Verbindungen. Weitere Informationen zum Alarmprotokoll für abgebrochene MySQL-Verbindungen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!