Der Common MySQL-Fehler:„Erhielt einen Fehler beim Lesen des Kommunikationspakets“

MySQL ist laut der DB Engine-Website hinter Oracle die zweitberühmteste Datenbank der Welt. Was MySQL berühmt macht, ist wahrscheinlich, weil es ein sehr schnelles, zuverlässiges und flexibles Datenbankmanagementsystem ist. MySQL ist auch eine der unterstützten Datenbanken in ClusterControl. Sie können ClusterControl ganz einfach bereitstellen, skalieren, überwachen und viele Dinge tun.

Heute werden wir über keinen davon sprechen, aber wir werden einen der häufigsten Fehler für MySQL und mögliche Tipps zur Fehlerbehebung besprechen. Bei der Arbeit mit Tickets sahen wir beim Überprüfen der Fehlerberichte oder -protokolle häufig diese Zeile „Fehler beim Lesen des Kommunikationspakets“. Wir denken, dass es sinnvoll wäre, wenn wir nicht nur für unsere Kunden, sondern auch für andere Leser einen Blog zu diesem Fehler schreiben würden. Warten wir nicht länger, es ist Zeit, weiter zu tauchen!

MySQL-Client/Server-Protokoll

Zunächst müssen wir verstehen, wie MySQL zwischen Client und Server kommuniziert. Sowohl der Client als auch der Server verwenden das MySQL-Protokoll, das durch Konnektoren, MySQL-Proxy und auch die Kommunikation zwischen Master- und Slave-Replikationsservern implementiert wird. Das MySQL-Protokoll unterstützt Funktionen wie transparente Verschlüsselung über SSL, transparente Komprimierung, eine Verbindungsphase sowie eine Befehlsphase.

Sowohl Integer als auch Strings sind die grundlegenden Datentypen, die im gesamten MySQL-Protokoll verwendet werden. Immer wenn MySQL-Client und -Server miteinander kommunizieren oder Daten senden möchten, werden die Daten in Pakete mit einer maximalen Größe von 16 MB aufgeteilt und jedem Chunk ein Paket-Header vorangestellt. In jedem Paket befindet sich eine Nutzlast, in der die Datentypen (Ganzzahlen/Strings) ihre Rolle spielen.

Da CLIENT_PROTOCOL_41 aktiviert ist, antwortet der Server auf fast jeden Befehl, den der Client an den Server sendet, mit einem der folgenden Pakete:

So diagnostizieren Sie die Probleme

Normalerweise gibt es zwei Arten von Verbindungsproblemen, nämlich Kommunikationsfehler oder abgebrochene Verbindungen. Wann immer eines dieser Verbindungsprobleme auftritt, sind die folgenden Informationsquellen ein guter Ausgangspunkt für die Fehlerbehebung und Analyse:

• Das Fehlerprotokoll

• Das allgemeine Abfrageprotokoll

• Die Statusvariablen Aborted_xxx und Connection_errors_xxx

• Der Host-Cache

Verbindungsfehler und mögliche Gründe

Wenn Verbindungsfehler auftreten, erhöht es abhängig von den Fehlern den Statuszähler entweder für Aborted_clients oder Aborted_connects in den Statusvariablen. Wie aus der MySQL-Dokumentation entnommen, bedeutet Aborted_clients die Anzahl der Verbindungen, die abgebrochen wurden, weil der Client starb, ohne die Verbindung ordnungsgemäß zu schließen. Aborted_connects bedeutet die Anzahl der fehlgeschlagenen Verbindungsversuche zum MySQL-Server.

Wenn Sie den MySQL-Server mit der Option --log-warnings starten, werden Sie wahrscheinlich das Beispiel der folgenden Meldung in Ihrem Fehlerprotokoll sehen. Wie Sie bemerkt haben, sagte die Nachricht eindeutig, dass sie sich auf die abgebrochene Verbindung bezieht, daher wird der Statuszähler Aborted_connects in der Statusvariablen inkrementiert:

[Warnung] Abgebrochene Verbindung 154669 zu db:'wordpress' Benutzer:'wpuser' Host:'Hostname' (Fehler beim Lesen von Kommunikationspaketen)

Normalerweise kann es aus folgenden Gründen zu erfolglosen Verbindungsversuchen kommen. Wenn Sie dies bemerken, deutet dies möglicherweise darauf hin, dass eine unbefugte Person im Begriff ist, die Datenbank zu verletzen, und Sie sollten sich diese so schnell wie möglich ansehen:

• Ein Client hat keine Zugriffsrechte auf die Datenbank.

• Es wurde ein falscher Berechtigungsnachweis verwendet.

• Ein Verbindungspaket mit falschen Informationen.

• Aufgrund des erreichten Limits für connect_timeout zum Verbinden.

Die Statusvariable für Aborted_clients wird vom Server erhöht, wenn ein Client eine Verbindung herstellen kann, aber die Verbindung getrennt oder auf unsachgemäße Weise beendet wird. Darüber hinaus protokolliert der Server auch eine Meldung über eine abgebrochene Verbindung im Fehlerprotokoll. Für diese Art von Fehlern kann es im Allgemeinen folgende Gründe geben:

• Der Client schließt die Verbindung vor dem Beenden nicht ordnungsgemäß (ruft mysql_close () nicht auf).

• Der Client hat wait_timeout oder interactive_timeout Sekunden überschritten.

• Das Client-Programm oder die Anwendung wurde plötzlich mitten in der Datenübertragung beendet.

Neben den oben genannten Gründen könnten andere wahrscheinliche Gründe sowohl für abgebrochene Verbindungen als auch für abgebrochene Client-Probleme mit einem der folgenden zusammenhängen:

• TCP/IP-Konfiguration vermasselt.

• Der Variablenwert ist zu klein für max_allowed_packet.

• Unzureichende Speicherzuordnung für Abfragen.

• Fehlerhafte Hardware wie Ethernet, Switches, Kabel usw.

• Probleme mit der Thread-Bibliothek.

• Duplex-Syndrom-Problem, bei dem die Übertragung im Burst-Pause-Burst-Pause-Modus erfolgt (wenn Sie das Ethernet-Protokoll verwenden mit Linux sowohl Halb- als auch Vollduplex).

So beheben Sie MySQL-Kommunikationsfehler

Nun, da wir viele Möglichkeiten kennengelernt haben, die MySQL-Verbindungsfehler verursacht haben. Unserer Erfahrung nach hängt dieses Problem meistens mit Firewall- oder Netzwerkproblemen zusammen. Es ist auch fair zu sagen, dass es nicht einfach ist, diese Art von Problem zu diagnostizieren. Dennoch könnte die folgende Lösung hilfreich sein, um diesen Fehler zu beheben:

• Wenn sich Ihre Anwendung auf das Wait_timeout verlässt, um die Verbindung zu schließen, lohnt es sich, die Anwendungslogik so zu ändern, dass dies der Fall ist am Ende jeder Operation ordnungsgemäß geschlossen.

• Stellen Sie sicher, dass der Wert für max_allowed_packet innerhalb des akzeptablen Bereichs liegt, damit der Client keinen Fehler in Bezug auf erhält das „Paket zu groß“.

• Bei Verbindungsverzögerungsproblemen, die auf das DNS zurückzuführen sein könnten, lohnt es sich zu prüfen, ob Sie skip-name- Auflösung aktiviert.

• Wenn Sie eine PHP-Anwendung oder eine andere Programmierung verwenden, stellen Sie am besten sicher, dass sie nicht abbricht die Verbindungen, die typischerweise auf max_execution_time gesetzt werden.

• Wenn Sie viele TIME_WAIT-Benachrichtigungen von netstat bemerkt haben, lohnt es sich zu bestätigen, dass die Verbindungen auf dem gut verwaltet werden Bewerbungsende.

• Wenn Sie Linux verwenden und vermuten, dass das Problem auf das Netzwerk zurückzuführen ist, überprüfen Sie am besten die Netzwerkschnittstelle indem Sie den Befehl ifconfig-a verwenden und die Ausgabe auf dem MySQL-Server auf Fehler untersuchen.

• Für ClusterControl-Benutzer können Sie das Audit-Protokoll über Cluster -> Sicherheit -> Audit-Protokoll aktivieren. Wenn Sie diese Funktion aktivieren, können Sie die Suche nach der schuldigen Suchanfrage eingrenzen.

• Netzwerktools wie tcpdump und Wireshark könnten hilfreich sein, um potenzielle Netzwerkprobleme, Zeitüberschreitungen und Ressourcenprobleme für MySQL zu identifizieren.

• Überprüfen Sie regelmäßig die Hardware, indem Sie sicherstellen, dass keine fehlerhaften Geräte vorhanden sind, insbesondere bei Ethernet, Hubs, Switches und Kabeln usw. Es lohnt sich, das defekte Gerät auszutauschen, um sicherzustellen, dass die Verbindung immer gut ist.

Fazit

Es gibt viele Gründe, die möglicherweise zu Problemen mit dem MySQL-Verbindungspaket führen könnten. Wann immer dieses Problem auftritt, wirkt es sich definitiv auf das Geschäft und den täglichen Betrieb aus. Auch wenn diese Art von Problem nicht einfach zu diagnostizieren ist und meistens auf das Netzwerk oder die Firewall zurückzuführen ist, lohnt es sich, alle zuvor vorgeschlagenen Schritte zur Behebung des Problems zu berücksichtigen. Wir hoffen wirklich, dass dieser Blogbeitrag Ihnen in irgendeiner Weise helfen kann, besonders wenn Sie mit diesem Problem konfrontiert sind.