Analyse der problematischen „Aborted“-Warnung in MySQL anhand von Fallstudien

Dieser Artikel stellt hauptsächlich den relevanten Inhalt zum abgebrochenen Alarm in MySQL vor und gibt ihn zu Ihrer Information und zum Lernen weiter. Werfen wir einen Blick auf die ausführliche Einführung:

Tatsächlicher Kampf

Teil 1: Am Anfang geschrieben

Im MySQL-Fehlerprotokoll sehen wir häufig verschiedene Arten von abgebrochenen Verbindungsfehlern. Dieser Artikel führt eine vorläufige Analyse solcher Fehler durch und erläutert die grundlegenden Ideen und Methoden zur Fehlerbehebung, wenn ein Problem auftritt. Es ist entscheidend, diese Methode zu beherrschen, anstatt bei auftretenden Problemen zu raten und es einfach auszuprobieren. Wenn ein Problem in der Datenbank auftritt, muss der DBA das Problem innerhalb kurzer Zeit schnell lösen. Darin liegt also der Unterschied zwischen einem guten und einem schlechten DBA.

Teil 2: Typen

[Warnung] Abgebrochene Verbindung 305628 zu db: „db“ Benutzer: „dbuser“ Host: „Hostname“ (Beim Lesen der Kommunikationspakete ist ein Fehler aufgetreten)
[Warnung] Abgebrochene Verbindung 81 zu db:'nicht verbunden' Benutzer: 'root' Host: '127.0.0.1' (Timeout beim Lesen der Kommunikation aufgetreten)
Pakete)
[Warnung] Abgebrochene Verbindung 109 zu db:'helei1' Benutzer: 'sys_admin' Host: '192.168.1.1' (Beim Schreiben der Kommunikationspakete ist ein Fehler aufgetreten)
[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[Warnung] Beim Schreiben der Kommunikationspakete ist ein Fehler aufgetreten

Teil 3: Schlüsselparameteranalyse

Wartezeit

Dieser Parameter gibt die Anzahl der Sekunden an, die der Server auf Aktivität bei einer nicht interaktiven Verbindung wartet, bevor er sie beendet.

interaktives_timeout

Dieser Parameter gibt die Anzahl der Sekunden an, die der Server auf Aktivität wartet, bevor eine interaktive Verbindung geschlossen wird.

Warnung: Es wird empfohlen, diese beiden Parameter zusammen anzupassen, um einige Fallstricke zu vermeiden.

Die beiden Parameterwerte in diesem Artikel verwenden die Standardwerte

mysql> zeige globale Variablen wie „%timeout%“;
+----------------------------+----------+
| Variablenname | Wert |
+----------------------------+----------+
| Verbindungstimeout | 10 |
| verzögertes_Einfügetimeout | 300 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | AUS |
|Interaktives_Timeout | 28800 |
| Wartezeit_für_Sperre | 31536000 |
| Zeitüberschreitung beim Lesen des Netzes | 30 |
| Zeitüberschreitung beim Schreiben von Nachrichten | 60 |
| Slave_Net_Timeout | 3600 |
|Wartezeitüberschreitung | 28800 |
+----------------------------+----------+
10 Zeilen im Satz (0,01 Sek.)

Darüber hinaus konzentrieren wir uns in der Datenbank auf diese beiden Parameter, um zu sehen, unter welchen Umständen Aborted_clients zunehmen und unter welchen Umständen Aborted_connects zunehmen

mysql>globalen Status wie „abgebrochen %“ anzeigen;
+------------------+--------+
|Variablenname | Wert |
+------------------+--------+
|Abgebrochene_Clients | 19 |
|Abgebrochene_Verbindungen | 0 |
+------------------+--------+
2 Zeilen Einschub (0,00 Sek.)

Teil 4: Fall 1

Hier habe ich absichtlich 5 Mal das falsche Passwort eingegeben, um zu sehen, welcher Parameter des Datenbankfehlerprotokolls und Aborted dieses Problem aufzeichnet

[root@HE3~]# mysql -uroot -pwrongpass -h127.0.0.1
FEHLER 1045 (28000): Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[root@HE3~]# mysql -uroot -pwrongpass -h127.0.0.1
FEHLER 1045 (28000): Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[root@HE3~]# mysql -uroot -pwrongpass -h127.0.0.1
FEHLER 1045 (28000): Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[root@HE3~]# mysql -uroot -pwrongpass -h127.0.0.1
FEHLER 1045 (28000): Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[root@HE3~]# mysql -uroot -pwrongpass -h127.0.0.1
FEHLER 1045 (28000): Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)

Es ist ersichtlich, dass Aborted_connects hier das Problem des falschen Passworts aufzeichnet

mysql>globalen Status wie „abgebrochen %“ anzeigen;
+------------------+--------+
|Variablenname | Wert |
+------------------+--------+
|Abgebrochene_Clients | 19 |
|Abgebrochene_Verbindungen | 5 |
+------------------+--------+
2 Zeilen Einschub (0,00 Sek.)

Das Fehlerprotokoll zeichnet auch solche Fehlerinformationen zur Kennworteingabe auf.

[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)
[Warnung] Zugriff für Benutzer „root“@„127.0.0.1“ verweigert (mit Passwort: JA)

Teil 5: Fall 2

Als nächstes betrachten wir die Auswirkungen der beiden in Abschnitt 3 genannten Schlüsselparameter auf das Verhalten von Datenbankverbindungen.

Hier konfigurieren wir beide Parameter auf 10 Sekunden

mysql>globales Wait_Timeout auf 10 setzen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
 
mysql>globales interaktives_Timeout = 10 festlegen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
mysql>Prozessliste anzeigen;
FEHLER 2006 (HY000): MySQL-Server ist weg
Keine Verbindung. Versuch, die Verbindung wiederherzustellen... Verbindungs-ID: 79 Aktuelle Datenbank: *** KEINE ***
 
+----+------+-----------------+------+---------+----------+-----------+------------------+
| ID | Benutzer | Host | db | Befehl | Zeit | Status | Info |
+----+------+-----------------+------+---------+----------+-----------+------------------+
| 79 |root | 127.0.0.1:42016 | NULL | Abfrage | 0 | NULL | Prozessliste anzeigen |
+----+------+-----------------+------+---------+----------+-----------+------------------+
1 Zeile im Satz (0,00 Sek.)

Hier sind drei Operationen. Sie können sehen, dass die Anzahl der Clients zunimmt. Dies liegt daran, dass der Timeout-Parameter die Verbindung steuert, die bereits eine Verbindung zu den Daten hergestellt hat und beendet wird.

mysql>globalen Status wie „abgebrochen %“ anzeigen;
FEHLER 2006 (HY000): MySQL-Server ist weg
Keine Verbindung. Versuch, die Verbindung wiederherzustellen... Verbindungs-ID: 81 Aktuelle Datenbank: *** KEINE ***
 
+------------------+--------+
|Variablenname | Wert |
+------------------+--------+
|Abgebrochene_Clients | 22 |
|Abgebrochene_Verbindungen | 5 |
+------------------+--------+
2 Zeilen im Satz (0,01 Sek.)

Das Fehlerprotokoll zeichnet

[Warnung] Abgebrochene Verbindung 81 zu db: „nicht verbunden“ Benutzer: „root“ Host: „127.0.0.1“ (Zeitüberschreitung beim Lesen der Kommunikationspakete aufgetreten)
[Warnung] Abgebrochene Verbindung 78 zu db: „nicht verbunden“ Benutzer: „root“ Host: „127.0.0.1“ (Zeitüberschreitung beim Lesen der Kommunikationspakete aufgetreten) 
[Warnung] Abgebrochene Verbindung 79 zu db: „nicht verbunden“ Benutzer: „root“ Host: „127.0.0.1“ (Zeitüberschreitung beim Lesen der Kommunikationspakete aufgetreten)

Teil 6: Fall 3

In diesem Fall untersuchen wir den Einfluss der maximalen Verbindungsanzahl auf das Verhalten von Datenbankverbindungen.

mysql>globale Variablen wie „max_conn%“ anzeigen;
+--------------------+----------+
|Variablenname | Wert |
+--------------------+----------+
|max_Verbindungsfehler | 1000 |
|max_Verbindungen | 1024 |
+--------------------+----------+
2 Zeilen im Satz (0,00 Sek.)
 
 
mysql>globale Max_Connections auf 2 setzen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

Hier sehe ich ein Problem mit zu vielen Verbindungen.

[root@HE3~]# mysql -uroot -pMANAGER -h127.0.0.1
FEHLER 1040 (HY000): Zu viele Verbindungen

Es gibt keinen Eintrag im Fehlerprotokoll

Teil 7: Fall 4

Wenn das Auswahlergebnis des Drittanbieter-Tools Navicat nicht angezeigt wird, wählen Sie „Stopp“ und es wird angezeigt

Kunden steigen

mysql>globalen Status wie „abgebrochen %“ anzeigen;
+------------------+--------+
|Variablenname | Wert |
+------------------+--------+
|Abgebrochene_Clients | 28 |
|Abgebrochene_Verbindungen | 10 |
+------------------+--------+
2 Zeilen im Satz (0,00 Sek.)

Fehlerprotokollierung

170626 16:26:56 [Warnung] Abgebrochene Verbindung 109 zu db: „helei1“ Benutzer: „sys_admin“ Host: „192.168.1.1“ (Beim Schreiben der Kommunikationspakete ist ein Fehler aufgetreten)

Teil 8: Zusammenfassung der Gründe

1. Verbindungen, die in MySQL Hunderte von Sekunden und oft wiederholt inaktiv sind, sind eines der Symptome dafür, dass eine Anwendung Verbindungen nach Feierabend nicht schließt, sondern sich zum Schließen auf das wait_timeout der Datenbank verlässt. Es wird dringend empfohlen, die Anwendungslogik zu ändern, um die Verbindung am Ende des Vorgangs ordnungsgemäß zu schließen.
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. In diesem Fall wird er die Verbindung abbrechen, anstatt sie ordnungsgemäß zu schließen.
3. Eine andere Möglichkeit ist TIME_WAIT. Es wird empfohlen, sicherzustellen, dass die Verbindung auf der Anwendungsseite ordnungsgemäß verwaltet und geschlossen wird.
4. Stellen Sie sicher, dass die Transaktion korrekt bestätigt (gestartet und bestätigt) wird, sodass sich die Anwendung in einem „sauberen“ Zustand befindet, sobald sie mit der Verbindung „fertig“ ist.
5. Sie sollten sicherstellen, dass die Client-Anwendung die Verbindung nicht abbricht. Wenn beispielsweise die PHP-Option „max_execution_time“ auf 5 Sekunden eingestellt ist, ist eine Erhöhung des „connect_timeout“ sinnlos, da PHP das Skript beendet. Andere Programmiersprachen und Umgebungen verfügen über ähnliche Möglichkeiten;
6. Ein weiterer Grund für Verbindungsverzögerungen sind DNS-Probleme. Überprüfen Sie, ob „Skip-Name-Resolve“ aktiviert ist. Dadurch wird überprüft, ob Hosts basierend auf ihren IP-Adressen und nicht auf ihren Hostnamen authentifiziert werden.
7. 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.

Zusammenfassen

Anhand dieser vier Fälle können wir den Unterschied zwischen Aborted_clients und Aborted_connects verstehen und feststellen, welche Art von Fehlerprotokoll unter welchen Umständen angezeigt wird. Die verschiedenen Aborted-Fehler im zweiten Abschnitt des Artikels sind häufige Fehler. Wenn solche Fehler auftreten, sollten Sie über theoretische Kenntnisse verfügen, um zu wissen, welche Art von Fehler unter welchen Umständen auftreten wird, um das Problem schnell zu lokalisieren. Aufgrund der begrenzten Kenntnisse des Autors und der Eile, den Artikel zu schreiben, enthält der Artikel zwangsläufig einige Fehler oder Ungenauigkeiten. Ich bitte die Leser aufrichtig, etwaige Unangemessenheiten zu kritisieren und zu korrigieren.

Nun, das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels Ihnen bei Ihrem Studium oder Ihrer Arbeit helfen kann. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.