In MySQL-Fehlerprotokollen werden einige Warnungen wie diese angezeigt:
120611 16:12:30 [Warning] Aborted connection 2619503 to db: "db_name" user: "user_name" host: "webapp_hostname" (Got an error reading communication packets)
Ich habe keinen Datenverlust per se bemerkt, daher frage ich mich, was diese Warnung bedeutet oder was sie verursacht und wie man das Problem beheben kann, das diese verursacht. Dies ist unter RHEL 6.1 und MySQL der Fall Enterprise 5.5.
Antwort
Einer der stillen Killer von MySQL Connections ist das MySQL-Paket.
Lassen Sie uns zunächst herausfinden, was ein MySQL-Paket ist.
Entsprechend der Seite 99 von „Understanding MySQL Internals“ (ISBN 0-596-00957) -7) , hier sind die Absätze 1-3, in denen MySQL-Pakete erläutert werden:
Der MySQL-Netzwerkkommunikationscode wurde unter der Annahme geschrieben, dass Abfragen immer sind relativ kurz und kann daher in einem Block an den Server gesendet und von diesem verarbeitet werden, der in der MySQL-Terminologie als Paket bezeichnet wird. Der Server reserviert den Speicher für einen temporären Puffer zum Speichern des Pakets und fordert genug an, um es vollständig anzupassen. Diese Architektur erfordert eine Vorsichtsmaßnahme, um zu vermeiden, dass dem Server der Arbeitsspeicher ausgeht – eine Begrenzung der Paketgröße, die mit dieser Option erreicht wird.
Der Code von Interesse in Bezug auf diese Option befindet sich in sql / net_serv.cc . Schauen Sie sich my_net_read () an und folgen Sie dem Aufruf von my_real_read () und achten Sie besonders auf net_realloc () .
Diese Variable begrenzt auch die Länge eines Ergebnisses vieler Zeichenfolgenfunktionen. Siehe sql / field.cc und sql / intem_strfunc.cc für Details.
Wenn ein Entwickler / DBA dies über MySQL-Pakete weiß, kann er sie für mehrere BLOBs skalieren in einem Paket, auch wenn sie unerträglich groß sind. Auf jeden Fall verursacht ein zu kleines Paket diesbezüglich Probleme für offene Verbindungen.
Gemäß MySQL-Dokumentation
-
Sie können diese Fehler auch erhalten, wenn Sie eine falsche oder auch eine falsche Anfrage an den Server senden groß. Wenn mysqld ein Paket empfängt, das zu groß oder nicht in Ordnung ist, wird davon ausgegangen, dass mit dem Client ein Fehler aufgetreten ist, und die Verbindung wird geschlossen. Wenn Sie große Abfragen benötigen (z. B. wenn Sie mit großen BLOB-Spalten arbeiten), können Sie das Abfragelimit erhöhen, indem Sie die Variable max_allowed_packet des Servers festlegen, die einen Standardwert von 1 MB hat. Möglicherweise müssen Sie auch das Maximum erhöhen Paketgröße auf Client-Seite. Weitere Informationen zum Festlegen der Paketgröße finden Sie in Abschnitt C.5.2.10, „Paket zu groß“.
-
Eine INSERT- oder REPLACE-Anweisung, die sehr viele Zeilen einfügt, kann ebenfalls diese Art von Fehlern verursachen. Jede dieser Anweisungen sendet eine einzelne Anforderung an den Server, unabhängig von der Anzahl der einzufügenden Zeilen Daher können Sie den Fehler häufig vermeiden, indem Sie die Anzahl der pro EINFÜGEN oder ERSETZEN gesendeten Zeilen verringern.
EMPFEHLUNG
Versuchen Sie, die max_allowed_packet auf eine viel größere Zahl, da der Standardwert 1M ist Ich würde ungefähr das Zehnfache des größten TEXT- oder BLOB-Felds vorschlagen, das Sie in Ihrem aktuellen Datensatz haben.
Um das max_allowed_packet auf 256 MB festzulegen, können Sie es zu /etc/my.cnf oder my.ini p hinzufügen >
[mysqld] max_allowed_packet=256M
für zukünftige Neustarts von mysqld. Um den Wert jetzt auf dem Server zu installieren, führen Sie Folgendes aus:
SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;
Probieren Sie es aus !!!
Kommentare
- Sehr gute Erklärung.
- @RolandoMySQLDBA Ich erhalte immer noch eine Fehlermeldung in 5.7.28, nachdem ich alle genannten Lösungen ausprobiert habe. Tipps zur weiteren Fehlerbehebung
Antwort
Meistens sind max_connections standardmäßig 100. Versuchen Sie, den Konfigurationsparameter
max_connections = 400, nachdem Sie in my.cnf den Server neu gestartet oder dynamisch eingestellt haben:
set @@global.max_connections = 400;
Versuchen Sie einfach die obige Empfehlung an Vermeiden Sie diese Warnmeldungen und stellen Sie außerdem sicher, dass in Ihrem Netzwerk keine Pakete verworfen werden.
Antwort
Dieses Problem ist kürzlich nach dem Wechsel von aufgetreten MySQL Enterprise 5.1.x bis 5.7.x , ohne wesentliche Codeänderungen an der Anwendung, wurde der Hinweis „ note “ angezeigt.
In meinem Fall war die Hauptursache für die Anzeige von „ note “ das Programm, das mit noch offenen Verbindungen beendet wurde.Die Umstände, dass Verbindungen nicht geschlossen wurden, waren etwas komplizierter und bezogen sich nicht auf MySQL, sondern auf ACE, Threads und TSS.
Antwort
Hier nicht erwähnt, daher füge ich eine weitere Ursache für dieses Problem hinzu. In meinem Fall wurde der Fehler bei Verwendung des MySQL-Befehlszeilenclients durch einen niedrigen Wert von 30 Sekunden von interactive_timeout
verursacht:
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_interactive_timeout
Dies bleibt über Sitzungen hinweg bestehen, jedoch nicht über einen Neustart des Servers.
SET GLOBAL interactive_timeout=6000;
Antwort
Ich bin auf dasselbe Problem mit MariaDB 10.3.24 gestoßen. Es scheint, dass die Warnung aus all den oben genannten und noch einigen anderen Gründen auftreten kann. In meinem Fall lag es an einem Datensatz in einer der Datenbanktabellen, der einen leeren Wörterbuchwert für eines der Felder hatte.
+ —- + ——– + | id | config | + —- + ——– + | 3 | {} | + —- + ——– +
Als Test habe ich „{}“ in „()“ geändert und dadurch die Nachricht gestoppt. Nur für den Fall, dass es jemandem hilft.
Antwort
Diese my.ini-Zeile hat mein Problem gelöst:
log_error_verbosity=1
Referenz dieser Link
Kommentare
- Ich glaube nicht, dass Sie das zugrunde liegende Problem gelöst haben, sondern einfach aufgehört haben, es zu protokollieren.
- Ich habe dieselbe Nachricht als a gemeldet bekommen. id id = "3926e395f9">
" Hinweis ". Die Verwendung von log_error_verbosity = 2 löst tatsächlich das Problem " " (aber eine " Warnung " sollte angesprochen, nicht ignoriert werden)