FEHLER 2006 (HY000): Der MySQL-Server ist verschwunden

Ich erhalte diesen Fehler, wenn ich versuche, eine große SQL-Datei (eine große INSERTAbfrage) zu erstellen .

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

Nichts in der Tabelle wird aktualisiert. Ich habe versucht, die Tabelle / Datenbank zu löschen und wieder zu löschen sowie MySQL neu zu starten. Keines dieser Dinge löst das Problem.

Hier ist meine maximale Paketgröße:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

Hier ist die Dateigröße:

$ ls -s file.sql 
79512 file.sql

Wenn ich die andere Methode versuche ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

Das Hinzufügen dieser Zeile zur my.cnfDatei löst mein Problem.

Dies ist nützlich, wenn die Spalten große Werte haben, die die Probleme verursachen. Die Erklärung finden Sie hier .

Unter Windows befindet sich diese Datei unter: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

Unter Linux (Ubuntu): / etc / mysql

Sie können das maximal zulässige Paket erhöhen

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

Das globale Update und die my.cnf-Einstellungen haben aus irgendeinem Grund bei mir nicht funktioniert. Die Übergabe des max_allowed_packetWertes direkt an den Kunden hat hier funktioniert:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

Im Allgemeinen ist der Fehler:

Fehler: 2006 ( CR_SERVER_GONE_ERROR) - Der MySQL-Server ist verschwunden

bedeutet, dass der Client keine Frage an den Server senden konnte .

mysql importieren

In Ihrem speziellen Fall bedeutet dies beim Importieren der Datenbankdatei über mysqlhöchstwahrscheinlich, dass einige der Abfragen in der SQL-Datei zu groß zum Importieren sind und nicht auf dem Server ausgeführt werden können. Daher schlägt der Client beim ersten aufgetretenen Fehler fehl.

Sie haben also folgende Möglichkeiten:

• Option Force hinzufügen (-f ) hinzu, um mysqlfortzufahren und die restlichen Abfragen auszuführen.

  Dies ist nützlich, wenn die Datenbank einige große Abfragen im Zusammenhang mit dem Cache enthält, die ohnehin nicht relevant sind.

• Erhöhen Sie max_allowed_packetundwait_timeout in Ihrer Serverkonfiguration (z~/.my.cnf ).

• Speichern Sie die Datenbank mit --skip-extended-insert Option, um die großen Abfragen aufzuschlüsseln. Dann importieren Sie es erneut.

• Versuchen Sie, die --max-allowed-packetOption für anzuwenden mysql.

Häufige Gründe

Im Allgemeinen kann dieser Fehler verschiedene Dinge bedeuten, wie zum Beispiel:

• Eine Abfrage an den Server ist falsch oder zu groß.

  Lösung: Variable erhöhenmax_allowed_packet .

  • Stellen Sie sicher, dass sich die Variable unter [mysqld]Abschnitt befindet, nicht [mysql].

  • Haben Sie keine Angst, große Zahlen zum Testen zu verwenden (wie 1G).

  • Vergessen Sie nicht, den MySQL / MariaDB-Server neu zu starten.

  • Überprüfen Sie, ob der Wert richtig eingestellt wurde durch:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• Sie haben eine Zeitüberschreitung von der TCP / IP-Verbindung auf der Clientseite erhalten.

  Lösung: Variable erhöhenwait_timeout .

• Sie haben versucht, eine Abfrage auszuführen, nachdem die Verbindung zum Server geschlossen wurde.

  Lösung: Ein logischer Fehler in der Anwendung sollte behoben werden.

• Die Suche nach Hostnamen ist fehlgeschlagen (z. B. DNS-Serverproblem) oder der Server wurde mit der --skip-networkingOption gestartet .

  Eine andere Möglichkeit besteht darin, dass Ihre Firewall den MySQL-Port blockiert (z. B. standardmäßig 3306).

• Der laufende Thread wurde beendet. Versuchen Sie es erneut.

• Sie haben einen Fehler festgestellt, bei dem der Server während der Ausführung der Abfrage gestorben ist.

• Ein Client, der auf einem anderen Host ausgeführt wird, verfügt nicht über die erforderlichen Berechtigungen zum Herstellen einer Verbindung.

• Weitere Informationen finden Sie unter : B.5.2.9 Der MySQL-Server ist verschwunden .

Debuggen

Hier sind einige Debug-Ideen auf Expertenebene:

• Überprüfen Sie die Protokolle, z

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• Testen Sie Ihre Verbindung über mysql, telnetoder Ping - Funktionen (zB mysql_pingin PHP).

• Verwenden Sie tcpdumpdiese Option, um die MySQL-Kommunikation zu überwachen (funktioniert nicht für Socket-Verbindungen), z.

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• Verwenden Sie unter Linux strace. Verwenden Sie auf BSD / Mac dtrace/ dtruss, z

  sudo dtruss -a -fn mysqld 2>&1

  Siehe: Erste Schritte mit DTracing MySQL

Weitere Informationen zum Debuggen von MySQL-Servern oder -Clients finden Sie unter: 26.5 Debuggen und Portieren von MySQL .

Überprüfen Sie als Referenz den Quellcode in der sql-common/client.cDatei, die für das Auslösen des CR_SERVER_GONE_ERRORFehlers für den Clientbefehl verantwortlich ist.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

Nur für den Fall, um Variablen zu überprüfen, die Sie verwenden können

$> mysqladmin variables -u user -p 

Dadurch werden die aktuellen Variablen angezeigt, in diesem Fall max_allowed_packet, und wie in einer anderen Antwort angegeben, können Sie sie vorübergehend festlegen

mysql> SET GLOBAL max_allowed_packet=1072731894

In meinem Fall wurde die cnf-Datei nicht berücksichtigt und ich weiß nicht warum, daher hat der SET GLOBAL-Code wirklich geholfen.

Ich habe den Fehler behoben ERROR 2006 (HY000) at line 97: MySQL server has gone awayund eine SQL-Datei mit> 5 GB erfolgreich migriert, indem ich die beiden folgenden Schritte ausgeführt habe:

1. Erstellt /etc/my.cnf wie von anderen empfohlen, mit folgenden Inhalten:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. Anhängen der Flags --force --wait --reconnectan den Befehl (dh mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Wichtiger Hinweis: Es war notwendig, beide Schritte auszuführen, da einige der Tabellen nach dem Import fehlten, wenn ich nicht die Änderungen an der Datei /etc/my.cnf vorgenommen und diese Flags angehängt habe.

Verwendetes System: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 für osx10.8 (i386)

Ich hatte das gleiche Problem, aber das Ändern von max_allowed_packet in der Datei my.ini / my.cnf unter [mysqld] machte den Trick.

füge eine Zeile hinzu

max_allowed_packet=500M

Starten Sie jetzt den MySQL-Dienst neu, sobald Sie fertig sind.

Sie können sich auch als root (oder SUPER-Berechtigung) bei der Datenbank anmelden und dies tun

set global max_allowed_packet=64*1024*1024;

erfordert auch keinen MySQL-Neustart. Beachten Sie, dass Sie Ihre my.cnfDatei wie in anderen Lösungen beschrieben reparieren sollten :

[mysqld]
max_allowed_packet=64M

Und bestätigen Sie die Änderung nach dem Neustart von MySQL:

show variables like 'max_allowed_packet';

Sie können auch die Befehlszeile verwenden, dies erfordert jedoch möglicherweise die Aktualisierung der Start / Stopp-Skripte, die Systemaktualisierungen und Patches möglicherweise nicht überleben.

Wie gewünscht, füge ich hier meine eigene Antwort hinzu. Schön zu sehen, dass es funktioniert!

Die Lösung besteht darin, die Werte wait_timeoutund connect_timeoutParameter in Ihrer Optionsdatei unter dem [mysqld]Tag zu erhöhen .

Ich musste ein 400-MB-MySQL-Backup wiederherstellen, und das hat bei mir funktioniert (die Werte, die ich unten verwendet habe, sind etwas übertrieben, aber Sie verstehen, worum es geht):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

Blockquote

Hier könnten ein paar Dinge passieren;

• Ihr INSERTläuft lange und der Client trennt die Verbindung. Wenn die Verbindung wiederhergestellt wird, wird keine Datenbank ausgewählt, daher der Fehler. Eine Möglichkeit besteht darin, Ihre Batchdatei über die Befehlszeile auszuführen und die Datenbank in den Argumenten wie folgt auszuwählen.

$ mysql db_name <source.sql

• Eine andere Möglichkeit besteht darin, Ihren Befehl über phpoder eine andere Sprache auszuführen . Nach jeder lang laufenden Anweisung können Sie die Verbindung schließen und erneut öffnen, um sicherzustellen, dass Sie zu Beginn jeder Abfrage verbunden sind.

Wenn Sie auf einem Mac sind und MySQL über Brew wie ich installiert haben, hat Folgendes funktioniert.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Quelle: Wo ist my.cnf für Homebrew-MySQL-Installationen?

2. hinzufügen max_allowed_packet=1073741824zu/usr/local/etc/my.cnf

3. mysql.server restart

Ich habe diesen Fehler festgestellt, wenn ich MySQL-Cluster verwende. Ich weiß nicht, ob diese Frage von einer Cluster-Verwendung stammt oder nicht. Da der Fehler genau der gleiche ist, geben Sie hier meine Lösung an. Dieser Fehler wird angezeigt, weil die Datenknoten plötzlich abstürzen. Wenn die Knoten jedoch abstürzen, können Sie mit cmd immer noch das richtige Ergebnis erzielen:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Und das mysqld funktioniert auch richtig. Also kann ich zunächst nicht verstehen, was falsch ist. Und ungefähr 5 Minuten später zeigt das Ergebnis ndb_mgm, dass kein Datenknoten funktioniert. Dann erkenne ich das Problem. Versuchen Sie also, alle Datenknoten neu zu starten. Dann ist der MySQL-Server wieder verfügbar und alles ist in Ordnung.

Aber eines ist seltsam für mich, nachdem ich den MySQL-Server für einige Abfragen verloren habe, wenn ich cmd like verwende show tables immer noch die Rückgabeinformationen wie erhalten33 rows in set (5.57 sec) , aber es werden keine Tabelleninformationen angezeigt.

Für Amazon RDS (es ist mein Fall) können Sie den max_allowed_packetParameterwert in einen beliebigen numerischen Wert in Byte ändern, der für die größten Daten in einer beliebigen Einfügung sinnvoll ist (z. B.: Wenn Ihre Einfügung einige 50-MB-Blob-Werte enthält, legen Sie den Wert fest max_allowed_packetbis 64M = 67108864), in einem neuen oder vorhandenen parameter-group. Wenden Sie diese Parametergruppe dann auf Ihre MySQL-Instanz an (möglicherweise muss die Instanz neu gestartet werden).

Wenn die Verbindung wiederhergestellt wird und die Verbindungs-ID 2 abgerufen wird, ist der Server fast definitiv gerade abgestürzt.

Wenden Sie sich an den Serveradministrator, um das Problem zu diagnostizieren. Kein nicht böswilliges SQL sollte den Server zum Absturz bringen, und die Ausgabe von mysqldump sollte es sicherlich nicht.

Es ist wahrscheinlich der Fall, dass der Serveradministrator einen großen Betriebsfehler gemacht hat, z. B. das Zuweisen von Puffergrößen, die größer als die Adressraumgrenzen der Architektur oder größer als die Kapazität des virtuellen Speichers sind. Das MySQL-Fehlerprotokoll enthält wahrscheinlich einige relevante Informationen. Sie werden dies überwachen, wenn sie trotzdem kompetent sind.

Dies ist eher ein seltenes Problem, aber ich habe dies gesehen, wenn jemand das gesamte Verzeichnis / var / lib / mysql kopiert hat, um seine Datenbank auf einen anderen Server zu migrieren. Der Grund, warum es nicht funktioniert, ist, dass die Datenbank ausgeführt wurde und Protokolldateien verwendet. Es funktioniert manchmal nicht, wenn sich Protokolle in / var / log / mysql befinden. Die Lösung besteht darin, auch die Dateien / var / log / mysql zu kopieren.

Für Drupal 8-Benutzer, die nach einer Lösung für einen DB-Importfehler suchen:

Am Ende der SQL-Dump-Datei können Befehle zum Einfügen von Daten in die Tabelle "webprofiler" stehen. Das ist wohl eine Debug-Protokolldatei, die für die Site nicht wirklich wichtig ist, damit all dies entfernt werden kann. Ich habe alle diese Einfügungen gelöscht, einschließlich LOCK TABLES und UNLOCK TABLES (und alles dazwischen). Es befindet sich ganz unten in der SQL-Datei. Das Problem wird hier beschrieben:

https://www.drupal.org/project/devel/issues/2723437

Aber es gibt keine Lösung dafür, außer diese Tabelle abzuschneiden.

Übrigens habe ich alle Lösungen aus den obigen Antworten ausprobiert und nichts anderes hat geholfen.

Ich habe alle oben genannten Lösungen ausprobiert, alle sind fehlgeschlagen.

Am Ende habe ich -h 127.0.0.1statt Standard verwendet var/run/mysqld/mysqld.sock.

Diese Fehlermeldung tritt auch auf, wenn Sie das SCHEMA mit einer anderen COLLATION als der im Dump verwendeten erstellt haben. Also, wenn der Dump enthält

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Sie sollten dies auch in der SCHEMA-Zusammenstellung berücksichtigen:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Ich hatte utf8mb4_general_ci im Schema verwendet, weil mein Skript aus einer neuen V8-Installation stammte. Jetzt lud das Laden einer Datenbank auf altem 5.7 ab und machte mich fast verrückt.

Vielleicht hilft dir das, ein paar frustierende Stunden zu sparen ... :-)

(MacOS 10.3, MySQL 5.7)

Wenn keine dieser Antworten das Problem löst, habe ich es gelöst, indem ich die Tabellen entfernt und sie auf diese Weise automatisch neu erstellt habe:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

Verwenden Sie dieses Backup dann einfach mit Ihrer Datenbank und es werden die benötigten Tabellen entfernt und neu erstellt.

Dann sichern Sie nur Daten und machen dasselbe, und es wird funktionieren.

Wie wäre es mit dem MySQL-Client wie folgt:

mysql -h <hostname> -u username -p <databasename> < file.sql