ERREUR 2006 (HY000): le serveur MySQL est parti

J'obtiens cette erreur lorsque j'essaye de trouver un gros fichier SQL (une grosse INSERTrequête).

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 ***

Rien dans le tableau n'est mis à jour. J'ai essayé de supprimer et de restaurer la table / base de données, ainsi que de redémarrer MySQL. Aucune de ces choses ne résout le problème.

Voici ma taille maximale de paquet:

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

Voici la taille du fichier:

$ ls -s file.sql 
79512 file.sql

Quand j'essaye l'autre méthode ...

$ ./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

L'ajout de cette ligne dans un my.cnffichier résout mon problème.

Ceci est utile lorsque les colonnes ont de grandes valeurs, ce qui provoque des problèmes, vous pouvez trouver l'explication ici .

Sous Windows, ce fichier se trouve dans: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

Sous Linux (Ubuntu): / etc / mysql

Vous pouvez augmenter le nombre maximal de paquets autorisés

SET GLOBAL max_allowed_packet=1073741824;

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

La mise à jour globale et les paramètres my.cnf n'ont pas fonctionné pour moi pour une raison quelconque. Passer la max_allowed_packetvaleur directement au client a fonctionné ici:

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

En général, l'erreur:

Erreur: 2006 ( CR_SERVER_GONE_ERROR) - Le serveur MySQL est parti

signifie que le client n'a pas pu envoyer de question au serveur .

mysql importer

Dans votre cas spécifique lors de l'importation du fichier de base de données via mysql, cela signifie très probablement que certaines des requêtes dans le fichier SQL sont trop volumineuses pour être importées et qu'elles n'ont pas pu être exécutées sur le serveur, donc le client échoue lors de la première erreur survenue.

Vous avez donc les possibilités suivantes:

• Ajoutez l'option force ( -f) pour mysqlcontinuer et exécuter le reste des requêtes.

  Cela est utile si la base de données contient de grandes requêtes liées au cache qui ne sont pas pertinentes de toute façon.

• Augmentez max_allowed_packetetwait_timeout dans la configuration de votre serveur (par exemple ~/.my.cnf).

• Vider la base de données à l'aide de l' --skip-extended-insertoption pour décomposer les grandes requêtes. Importez-le ensuite à nouveau.

• Essayez d'appliquer l' --max-allowed-packetoption pour mysql.

Raisons courantes

En général, cette erreur peut signifier plusieurs choses, telles que:

• une requête au serveur est incorrecte ou trop volumineuse,

  Solution: augmenter la max_allowed_packetvariable .

  • Assurez-vous que la variable est sous la [mysqld]section, non [mysql].

  • N'ayez pas peur d'utiliser de grands nombres pour les tests (comme 1G).

  • N'oubliez pas de redémarrer le serveur MySQL / MariaDB.

  • Vérifiez que la valeur a été correctement définie par:

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

• Vous avez obtenu un délai d'expiration de la connexion TCP / IP côté client.

  Solution: augmenter la wait_timeoutvariable .

• Vous avez tenté d'exécuter une requête après la fermeture de la connexion au serveur.

  Solution: une erreur logique dans l'application doit être corrigée.

• Les recherches de nom d'hôte ont échoué (par exemple, problème de serveur DNS) ou le serveur a été démarré avec l' --skip-networkingoption.

  Une autre possibilité est que votre pare-feu bloque le port MySQL (par exemple 3306 par défaut).

• Le thread en cours d'exécution a été tué, essayez à nouveau.

• Vous avez rencontré un bogue où le serveur est mort lors de l'exécution de la requête.

• Un client s'exécutant sur un hôte différent n'a pas les privilèges nécessaires pour se connecter.

• Et bien d'autres, alors apprenez-en plus sur: B.5.2.9 Le serveur MySQL est parti .

Débogage

Voici quelques idées de débogage de niveau expert:

• Vérifiez les journaux, par exemple

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

• Testez votre connexion via mysql, telnetou les fonctions ping (par exemple mysql_pingen PHP).

• Utilisez tcpdumppour renifler la communication MySQL (ne fonctionnera pas pour la connexion socket), par exemple:

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

• Sous Linux, utilisez strace. Sur BSD / Mac, utilisez dtrace/ dtruss, par exemple

  sudo dtruss -a -fn mysqld 2>&1

  Voir: Premiers pas avec DTracing MySQL

Apprenez-en plus sur le débogage du serveur ou client MySQL sur: 26.5 Débogage et portage de MySQL .

Pour référence, vérifiez le code source dans le sql-common/client.cfichier responsable du lancement de l' CR_SERVER_GONE_ERRORerreur pour la commande client.

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;
}

Juste au cas où, pour vérifier les variables que vous pouvez utiliser

$> mysqladmin variables -u user -p 

Cela affichera les variables actuelles, dans ce cas max_allowed_packet, et comme quelqu'un l'a dit dans une autre réponse, vous pouvez le définir temporairement avec

mysql> SET GLOBAL max_allowed_packet=1072731894

Dans mon cas, le fichier cnf n'a pas été pris en compte et je ne sais pas pourquoi, donc le code SET GLOBAL a vraiment aidé.

J'ai résolu l'erreur ERROR 2006 (HY000) at line 97: MySQL server has gone awayet réussi à migrer un fichier sql> 5 Go en effectuant ces deux étapes dans l'ordre:

1. Créé /etc/my.cnf comme d'autres l'ont recommandé, avec le contenu suivant:

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

2. Ajout des drapeaux --force --wait --reconnectà la commande (ie mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Remarque importante: Il était nécessaire d'effectuer les deux étapes, car si je ne prenais pas la peine d'apporter les modifications au fichier /etc/my.cnf ainsi que d'ajouter ces indicateurs, certaines tables manquaient après l'importation.

Système utilisé: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 pour osx10.8 (i386)

J'ai eu le même problème mais changer max_allowed_packet dans le fichier my.ini / my.cnf sous [mysqld] a fait l'affaire.

ajouter une ligne

max_allowed_packet=500M

redémarrez maintenant le service MySQL une fois que vous avez terminé.

Vous pouvez également vous connecter à la base de données en tant que root (ou privilège SUPER) et faire

set global max_allowed_packet=64*1024*1024;

ne nécessite pas de redémarrage MySQL également. Notez que vous devez corriger votre my.cnffichier comme indiqué dans d'autres solutions:

[mysqld]
max_allowed_packet=64M

Et confirmez la modification après avoir redémarré MySQL:

show variables like 'max_allowed_packet';

Vous pouvez également utiliser la ligne de commande, mais cela peut nécessiter la mise à jour des scripts de démarrage / d'arrêt qui peuvent ne pas survivre aux mises à jour et aux correctifs du système.

Comme demandé, j'ajoute ma propre réponse ici. Heureux de voir que cela fonctionne!

La solution augmente les valeurs données par le wait_timeoutet les connect_timeoutparamètres dans votre fichier d'options, sous l' [mysqld]étiquette.

J'ai dû récupérer une sauvegarde mysql de 400 Mo et cela a fonctionné pour moi (les valeurs que j'ai utilisées ci-dessous sont un peu exagérées, mais vous obtenez le point):

[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

Deux choses pourraient se produire ici;

• Votre INSERTfonctionne depuis longtemps et le client se déconnecte. Lorsqu'il se reconnecte, il ne sélectionne pas de base de données, d'où l'erreur. Une option ici consiste à exécuter votre fichier de commandes à partir de la ligne de commande et à sélectionner la base de données dans les arguments, comme ceci;

$ mysql nom_base <source.sql

• Une autre consiste à exécuter votre commande via phpou dans une autre langue. Après chaque instruction longue, vous pouvez fermer et rouvrir la connexion, en vous assurant que vous êtes connecté au début de chaque requête.

Si vous êtes sur Mac et avez installé mysql via brew comme moi, ce qui suit a fonctionné.

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

Source: Pour les installations homebrew mysql, où est my.cnf?

2. ajouter max_allowed_packet=1073741824à/usr/local/etc/my.cnf

3. mysql.server restart

J'ai rencontré cette erreur lorsque j'utilise Mysql Cluster, je ne sais pas si cette question provient d'une utilisation de cluster ou non. Comme l'erreur est exactement la même, donnez ma solution ici. Obtention de cette erreur car les nœuds de données se bloquent soudainement. Mais lorsque les nœuds se bloquent, vous pouvez toujours obtenir le résultat correct en utilisant cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Et le mysqld fonctionne également correctement. Donc, au début, je ne peux pas comprendre ce qui ne va pas. Et environ 5 minutes plus tard, le résultat ndb_mgm montre qu'aucun nœud de données ne fonctionne. Ensuite, je me rends compte du problème. Alors, essayez de redémarrer tous les nœuds de données, puis le serveur mysql est de retour et tout est OK.

Mais une chose est bizarre pour moi, après avoir perdu le serveur mysql pour certaines requêtes, lorsque j'utilise cmd like show tables, je peux toujours obtenir les informations de retour comme 33 rows in set (5.57 sec), mais aucune information de table n'est affichée.

Pour amazon RDS (c'est mon cas), vous pouvez changer la max_allowed_packetvaleur du paramètre en n'importe quelle valeur numérique en octets qui a du sens pour les plus grandes données dans n'importe quel insert que vous pourriez avoir (par exemple: si vous avez des valeurs de blob de 50 Mo dans votre insert, définissez le max_allowed_packetà 64M = 67108864), dans un nouveau ou existant parameter-group. Ensuite, appliquez ce groupe de paramètres à votre instance MySQL (peut nécessiter un redémarrage de l'instance).

S'il se reconnecte et obtient l'ID de connexion 2, le serveur vient presque définitivement de planter.

Contactez l'administrateur du serveur et demandez-lui de diagnostiquer le problème. Aucun SQL non malveillant ne devrait planter le serveur, et la sortie de mysqldump ne devrait certainement pas.

Il est probable que l'administrateur du serveur ait commis de grosses erreurs opérationnelles telles que l'attribution de tailles de mémoire tampon supérieures aux limites de l'espace d'adressage de l'architecture ou supérieures à la capacité de mémoire virtuelle. Le journal des erreurs MySQL contiendra probablement des informations pertinentes; ils surveilleront cela s'ils sont compétents de toute façon.

C'est plus un problème rare mais je l'ai vu si quelqu'un a copié tout le répertoire / var / lib / mysql comme moyen de migrer leur base de données vers un autre serveur. La raison pour laquelle cela ne fonctionne pas est que la base de données était en cours d'exécution et utilisait des fichiers journaux. Cela ne fonctionne pas parfois s'il y a des journaux dans / var / log / mysql. La solution consiste également à copier les fichiers / var / log / mysql.

Pour les utilisateurs de Drupal 8 à la recherche d'une solution pour l'échec de l'importation de base de données:

À la fin du fichier de vidage sql, il peut y avoir des commandes insérant des données dans la table "webprofiler". C'est, je suppose, un fichier journal de débogage et ce n'est pas vraiment important pour que le site fonctionne, donc tout cela peut être supprimé. J'ai supprimé toutes ces insertions, y compris LOCK TABLES et UNLOCK TABLES (et tout le reste). C'est tout en bas du fichier sql. Le problème est décrit ici:

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

Mais il n'y a pas d'autre solution que de tronquer ce tableau.

BTW J'ai essayé toutes les solutions des réponses ci-dessus et rien d'autre n'a aidé.

J'ai essayé toutes les solutions ci-dessus, toutes ont échoué.

J'ai fini par utiliser -h 127.0.0.1au lieu d'utiliser par défaut var/run/mysqld/mysqld.sock.

Ce message d'erreur se produit également lorsque vous avez créé le SCHEMA avec une COLLATION différente de celle qui est utilisée dans le vidage. Donc, si le vidage contient

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

vous devez également en tenir compte dans le classement SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

J'utilisais utf8mb4_general_ci dans le schéma, car mon script provenait d'une nouvelle installation V8, le chargement d'une base de données sur l'ancien 5.7 s'est écrasé et m'a rendu presque fou.

Donc, peut-être que cela vous aide à économiser des heures frustrantes ... :-)

(MacOS 10.3, mysql 5.7)

si aucune de ces réponses ne vous résout le problème, je l'ai résolu en supprimant les tables et en les recréant automatiquement de cette manière:

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

utilisez ensuite cette sauvegarde avec votre base de données et elle supprimera et recréera les tables dont vous avez besoin.

Ensuite, vous sauvegardez uniquement les données, et faites de même, et cela fonctionnera.

Que diriez-vous d'utiliser le client mysql comme ceci:

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