MySQL-Fehler 2006: MySQL-Server ist verschwunden

Ich verwende in meinem Büro einen Server, um einige Dateien zu verarbeiten und die Ergebnisse an einen Remote-MySQL-Server zu melden.

Die Dateiverarbeitung dauert einige Zeit und der Prozess endet zur Hälfte mit dem folgenden Fehler:

2006, MySQL server has gone away

Ich habe von der MySQL-Einstellung wait_timeout gehört , aber muss ich diese auf dem Server in meinem Büro oder auf dem Remote-MySQL-Server ändern?

Es ist möglicherweise einfacher, die Verbindung zu überprüfen und bei Bedarf wiederherzustellen.

Siehe PHP: mysqli_ping für Informationen dazu.

Ich bin mehrmals darauf gestoßen und habe normalerweise festgestellt, dass die Antwort eine sehr niedrige Standardeinstellung von ist max_allowed_packet.

Wenn Sie es in /etc/my.cnf(unter [mysqld]) auf 8 oder 16 M erhöhen, wird es normalerweise behoben. (Die Standardeinstellung in MySql 5.7 4194304ist 4 MB.)

[mysqld]
max_allowed_packet=16M

Hinweis: Erstellen Sie einfach die Zeile, wenn sie nicht vorhanden ist

Hinweis: Dies kann auf Ihrem Server während der Ausführung festgelegt werden.

Verwenden Sie set global max_allowed_packet=104857600. Dies setzt es auf 100 MB.

Ich hatte das gleiche Problem, aber das Ändern max_allowed_packetder my.ini/my.cnfDatei unter [mysqld]machte den Trick.

füge eine Zeile hinzu

max_allowed_packet = 500M

Jetzt, restart the MySQL servicewenn Sie fertig sind.

Ich habe den folgenden Befehl in der MySQL-Befehlszeile verwendet, um eine MySQL-Datenbank mit einer Größe von mehr als 7 GB wiederherzustellen, und sie funktioniert.

set global max_allowed_packet=268435456;

Fehler: 2006 ( CR_SERVER_GONE_ERROR )

Nachricht: Der MySQL-Server ist verschwunden

Im Allgemeinen können Sie erneut versuchen, eine Verbindung herzustellen, und dann die Abfrage erneut ausführen, um dieses Problem zu lösen. Versuchen Sie es 3-4 Mal, bevor Sie vollständig aufgeben.

Ich gehe davon aus, dass Sie PDO verwenden. Wenn ja, würden Sie die PDO-Ausnahme abfangen, einen Zähler erhöhen und es dann erneut versuchen, wenn der Zähler unter einem Schwellenwert liegt.

Wenn Sie eine Abfrage haben, die eine Zeitüberschreitung verursacht, können Sie diese Variable festlegen, indem Sie Folgendes ausführen:

SET @@GLOBAL.wait_timeout=300;
SET @@LOCAL.wait_timeout=300;  -- OR current session only

Wobei 300 die Anzahl der Sekunden ist, die die Abfrage Ihrer Meinung nach maximal dauern kann.

Weitere Informationen zum Umgang mit MySQL-Verbindungsproblemen.

BEARBEITEN: Zwei weitere Einstellungen, die Sie möglicherweise ebenfalls verwenden möchten, sind net_write_timeoutund net_read_timeout.

In MAMP (Non-Pro-Version) habe ich hinzugefügt

--max_allowed_packet=268435456

zu ...\MAMP\bin\startMysql.sh

Credits und mehr Details hier

Dieser Fehler tritt aufgrund des Ablaufs von wait_timeout auf.

Gehen Sie einfach zum MySQL-Server und überprüfen Sie das wait_timeout:

mysql> SHOW VARIABLES LIKE 'wait_timeout'

mysql> setze globales wait_timeout = 600 # 10 Minuten oder maximale Wartezeit, die du brauchst

http://sggoyal.blogspot.in/2015/01/2006-mysql-server-has-gone-away.html

Es gibt verschiedene Ursachen für diesen Fehler.

MySQL / MariaDB im Zusammenhang mit:

• wait_timeout - Zeit in Sekunden, die der Server wartet, bis eine Verbindung aktiv wird, bevor er geschlossen wird.
• interactive_timeout - Zeit in Sekunden, die der Server auf eine interaktive Verbindung wartet.
• max_allowed_packet- Maximale Größe eines Pakets oder einer generierten / Zwischenzeichenfolge in Byte. Stellen Sie so groß wie das größte BLOB ein, in Vielfachen von 1024.

Beispiel für my.cnf :

[mysqld]
# 8 hours
wait_timeout = 28800
# 8 hours
interactive_timeout = 28800
max_allowed_packet = 256M

Serverbezogen:

• Ihr Server verfügt über vollen Speicher - überprüfen Sie die Informationen zum RAM mit free -h

Rahmenbezogen:

• Überprüfen Sie die Einstellungen Ihres Frameworks. Django zum Beispiel verwenden CONN_MAX_AGE(siehe Dokumente )

So debuggen Sie:

• Überprüfen Sie die Werte der MySQL / MariaDB-Variablen.
  • mit sql: SHOW VARIABLES LIKE '%time%';
  • Befehlszeile: mysqladmin variables
• Aktivieren Sie die Ausführlichkeit für Fehler:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Weitere Informationen zum Fehler finden Sie in den Dokumenten

Unter Windows sollten die Benutzer von xampp diesen Pfad xampp / mysql / bin / my.ini verwenden und max_allowed_packet (unter Abschnitt [mysqld]) in die von Ihnen gewählte Größe ändern. z.B

max_allowed_packet=8M

Wieder auf php.ini (xampp / php / php.ini) ändern Sie upload_max_filesize die Auswahlgröße. z.B

upload_max_filesize=8M

Hat mir einige Zeit Kopfschmerzen bereitet, bis ich das entdeckte. Ich hoffe es hilft.

Ich habe denselben Fehler auf meinem DigitalOcean Ubuntu-Server erhalten.

Ich habe versucht, die Einstellungen für max_allowed_packet und wait_timeout zu ändern, aber keiner von beiden hat dies behoben.

Es stellt sich heraus, dass mein Server nicht mehr über genügend RAM verfügt. Ich habe eine 1-GB-Auslagerungsdatei hinzugefügt, wodurch mein Problem behoben wurde.

Überprüfen Sie Ihr Gedächtnis mit free -h, um festzustellen, ob dies die Ursache ist.

Es war ein RAM-Problem für mich.

Ich hatte das gleiche Problem sogar auf einem Server mit 12 CPU-Kernen und 32 GB RAM. Ich recherchierte mehr und versuchte, RAM freizugeben. Hier ist der Befehl, den ich unter Ubuntu 14.04 verwendet habe, um RAM freizugeben:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Und es hat alles repariert. Ich habe es unter Cron gesetzt, um jede Stunde zu laufen.

crontab -e

0 * * * * bash /root/ram.sh;

Mit diesem Befehl können Sie überprüfen, wie viel freier Arbeitsspeicher verfügbar ist:

free -h

Und Sie werden so etwas bekommen:

             total       used       free     shared    buffers     cached
Mem:           31G        12G        18G        59M       1.9G       973M
-/+ buffers/cache:       9.9G        21G
Swap:         8.0G       368M       7.6G

In meinem Fall war es ein niedriger Wert der open_files_limitVariablen, der den Zugriff von mysqld auf Datendateien blockierte.

Ich habe es überprüft mit:

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1185  |
+------------------+-------+
1 row in set (0.00 sec)

Nachdem ich die Variable auf großen Wert geändert hatte, war unser Server wieder aktiv:

[mysqld]
open_files_limit = 100000

Wenn Sie den 64-Bit-WAMPSERVER verwenden, suchen Sie bitte nach mehreren Vorkommen von max_allowed_packet, da WAMP den unter [wampmysqld64] festgelegten Wert verwendet und nicht den unter [mysqldump] festgelegten Wert, der für mich das Problem war. Ich habe den falschen aktualisiert. Setzen Sie dies auf etwas wie max_allowed_packet = 64M.

Hoffentlich hilft dies anderen Wampserver-Benutzern da draußen.

Dies weist im Allgemeinen auf Verbindungsprobleme oder Zeitüberschreitungen bei MySQL-Servern hin . Kann im Allgemeinen durch Ändern von wait_timeout und max_allowed_packet in my.cnf oder ähnlichem gelöst werden .

Ich würde diese Werte vorschlagen:

wait_timeout = 28800

max_allowed_packet = 8M

Stellen Sie für Vagrant Box sicher, dass Sie der Box genügend Speicher zuweisen

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
end

Das unwahrscheinliche Szenario ist, dass zwischen dem Client und dem Server eine Firewall besteht, die das Zurücksetzen von TCP in die Verbindung erzwingt.

Ich hatte dieses Problem und stellte fest, dass unsere Unternehmens-F5-Firewall so konfiguriert war, dass inaktive Sitzungen beendet werden, die länger als 5 Minuten inaktiv sind.

Dies ist wiederum das unwahrscheinliche Szenario.

Es ist immer eine gute Idee, die Protokolle des MySQL-Servers zu überprüfen, aus dem Grund, warum er verschwunden ist.

Es wird es dir sagen.

Wenn Sie einen xampp-Server verwenden:

Gehen Sie zu xampp -> mysql -> bin -> my.ini

Ändern Sie den folgenden Parameter:

max_allowed_packet = 500M

innodb_log_file_size = 128M

Das hat mir sehr geholfen :)

Kommentieren Sie das Ligne unten in Ihrem aus my.ini/my.cnf. Dadurch wird Ihre große Datei in einen kleineren Teil aufgeteilt

# binary logging format - mixed recommended
# binlog_format=mixed

ZU

# binary logging format - mixed recommended
binlog_format=mixed

Ich habe die Lösung für "# 2006 - MySQL Server ist weg" diesen Fehler gefunden. Die Lösung besteht nur darin, zwei Dateien zu überprüfen

1. config.inc.php
2. config.sample.inc.php

Pfad dieser Dateien in Windows ist

C:\wamp64\apps\phpmyadmin4.6.4

In diesen beiden Dateien ist der Wert davon:

$cfg['Servers'][$i]['host']must be 'localhost' .

In meinem Fall war es:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

ändere es in:

"$cfg['Servers'][$i]['host']" = 'localhost';

Stellen Sie in beiden sicher:

1. config.inc.php
2. config.sample.inc.php-Dateien müssen 'localhost' sein.

Und letzter Satz:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Starten Sie dann Wampserver neu.

So ändern Sie den Benutzernamen und das Passwort von phpmyadmin

Sie können den Benutzernamen und das Passwort von phpmyadmin direkt über die Datei config.inc.php ändern

Diese beiden Zeilen

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';

Hier können Sie einen neuen Benutzernamen und ein neues Passwort eingeben. Speichern Sie nach Änderungen die Datei und starten Sie den WAMP-Server neu.

Ich habe die Fehlermeldung 2006 in einer anderen MySQL-Client-Software auf meinem Ubuntu-Desktop erhalten. Es stellte sich heraus, dass meine JDBC-Treiberversion zu alt war.

Dies kann ein Problem Ihrer SQL-Dateigröße sein.

Wenn Sie xampp verwenden. Gehen Sie zur xampp-Systemsteuerung -> Klicken Sie auf MySql config -> Öffnen Sie my.ini.

Erhöhen Sie die Paketgröße.

max_allowed_packet = 2M -> 10M

Es gibt einen einfacheren Weg, wenn Sie XAMPP verwenden. Öffnen Sie das XAMPP-Kontrollfeld und klicken Sie auf die Schaltfläche config im Abschnitt mysql.

Klicken Sie nun auf die my.ini und sie wird im Editor geöffnet. Aktualisieren Sie das max_allowed_packet auf die gewünschte Größe.

Starten Sie dann den MySQL-Dienst neu. Klicken Sie im MySQL-Dienst auf Stopp. Klicken Sie erneut auf Start. Warten Sie einige Minuten.

Versuchen Sie dann erneut, Ihre MySQL-Abfrage auszuführen. Hoffe es wird funktionieren.

In MAMP 5.3 finden Sie my.cnf nicht und das Hinzufügen funktioniert nicht, da das max_allowed_packet in Variablen gespeichert ist.

Eine Lösung kann sein:

1. Gehen Sie zu http: // localhost / phpmyadmin
2. Gehen Sie zur Registerkarte SQL
3. Führen Sie SHOW VARIABLES aus und überprüfen Sie die Werte. Wenn sie klein sind, führen Sie sie mit großen Werten aus

4. Führen Sie die folgende Abfrage aus, und setzen Sie max_allowed_packet auf 7 GB:

   set global max_allowed_packet = 268435456;

Bei einigen müssen Sie möglicherweise auch die folgenden Werte erhöhen:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Für Benutzer, die XAMPP verwenden, gibt es in C: \ xampp \ mysql \ bin \ my.ini zwei Parameter für max_allowed_packet.

Dieser Fehler tritt grundsätzlich aus zwei Gründen auf.

1. Sie haben zu wenig RAM.
2. Die Datenbankverbindung wird geschlossen, wenn Sie versuchen, eine Verbindung herzustellen.

Sie können diesen Code unten versuchen.

# Simplification to execute an SQL string of getting a data from the database
def get(self, sql_string, sql_vars=(), debug_sql=0):
    try:            
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()
    except (AttributeError, MySQLdb.OperationalError):
        self.__init__()
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()

Es mildert den Fehler unabhängig vom Grund, insbesondere aus dem zweiten Grund.

Wenn es durch wenig RAM verursacht wird, müssen Sie entweder die Effizienz der Datenbankverbindung über den Code oder die Datenbankkonfiguration erhöhen oder einfach den RAM erhöhen.

Nur für den Fall, dass dies jemandem hilft:

Ich habe diesen Fehler erhalten, als ich Verbindungen in einer Funktion geöffnet und geschlossen habe, die von mehreren Teilen der Anwendung aufgerufen wurde. Wir haben zu viele Verbindungen, daher dachten wir, es wäre eine gute Idee, die vorhandene Verbindung wiederzuverwenden oder wegzuwerfen und eine neue wie folgt zu erstellen:

  public static function getConnection($database, $host, $user, $password)
 {
 if (!self::$instance) {
  return self::newConnection($database, $host, $user, $password);
 } elseif ($database . $host . $user != self::$connectionDetails) {

self :: $ instance-> query ('KILL CONNECTION_ID ()'); self :: $ instance = null; return self :: newConnection ($ database, $ host, $ user, $ password); } return self :: $ instance; } Nun, es stellt sich heraus, dass wir mit dem Töten etwas zu gründlich umgegangen sind und dass die Prozesse, die wichtige Dinge auf der alten Verbindung tun, ihr Geschäft niemals beenden könnten. Also haben wir diese Zeilen fallen gelassen

  self::$instance->query('KILL CONNECTION_ID()');
  self::$instance = null;

und da die Hardware und das Setup des Computers dies zulassen, haben wir die Anzahl der zulässigen Verbindungen auf dem Server durch Hinzufügen erhöht

max_connections = 500

zu unserer Konfigurationsdatei. Dies hat unser Problem vorerst behoben und wir haben etwas über das Beenden von MySQL-Verbindungen gelernt.

Wenn Sie wissen, dass Sie für eine Weile offline sind, können Sie Ihre Verbindung schließen, Ihre Verarbeitung durchführen, die Verbindung wiederherstellen und Ihre Berichte schreiben.