web-dev-qa-db-fra.com

ERREUR 2006 (HY000): le serveur MySQL est parti

Je reçois cette erreur lorsque j'essaie de créer un gros fichier SQL (une requête INSERT volumineuse).

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 d'annuler la suppression de 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 de paquet maximum:

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

Voici la taille du fichier:

$ ls -s file.sql 
79512 file.sql

Quand j'essaie 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
mysql
267
bgcode
max_allowed_packet=64M

L'ajout de cette ligne dans le fichier my.cnf résout mon problème.

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

Sous Windows, ce fichier se trouve à l'emplacement suivant: "C:\ProgramData\MySQL\MySQL Server 5.6"

Sous Linux (Ubuntu):/etc/mysql

493
Kurt Zhong

Vous pouvez augmenter le nombre maximum de paquets autorisés 

SET GLOBAL max_allowed_packet=1073741824;

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

123
Nanhe Kumar

La mise à jour globale et les paramètres my.cnf ne m'ont pas fonctionné pour une raison quelconque. Passer la valeur max_allowed_packet directement au client travaillé ici:

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

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 import

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

Donc, vous avez les possibilités suivantes:

  • Ajoutez l'option de force (-f) pour que mysql continue et exécute le reste des requêtes.

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

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

  • Videz la base de données en utilisant l'option --skip-extended-insert pour décomposer les requêtes volumineuses. Puis importez-le à nouveau.

  • Essayez d’appliquer l’option --max-allowed-packet pour mysql.

Raisons communes

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

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

    Solution: Augmenter max_allowed_packet variable.

    • Assurez-vous que la variable est sous la section [mysqld] et non pas [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 à nouveau que la valeur a été définie correctement par:

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

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

    Solution: Augmenter wait_timeout variable.

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

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

  • La recherche du nom d'hôte a échoué (par exemple, un problème de serveur DNS) ou le serveur a été démarré avec l'option --skip-networking.

    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é, alors réessayez.

  • Vous avez rencontré un bogue provoquant la mort du serveur lors de l'exécution de la requête.

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

  • Et bien d’autres encore, apprenez-en plus à l’adresse: 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 les fonctions mysql, telnet ou ping (par exemple, mysql_ping en PHP).

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

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

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

    Sudo dtruss -a -fn mysqld 2>&1

    Voir: Initiation à DTracing MySQL

Découvrez comment déboguer un serveur ou un client MySQL à l’adresse: 26.5 Débogage et portage de MySQL .

Pour référence, vérifiez le code source dans sql-common/client.c fichier responsable de la génération de l'erreur CR_SERVER_GONE_ERROR 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;
}
32
kenorb

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

$> mysqladmin variables -u user -p

Ceci 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, le code SET GLOBAL m'a vraiment aidé.

18
Zloy Smiertniy

J'ai résolu l'erreur ERROR 2006 (HY000) at line 97: MySQL server has gone away et migré avec succès un fichier SQL> 5 Go en effectuant les deux étapes suivantes:

  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 indicateurs --force --wait --reconnect à la commande (c'est-à-dire mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Remarque importante: Il était nécessaire d'exécuter les deux étapes, car si je ne m'occupais pas de modifier le fichier /etc/my.cnf ni d'ajouter ces indicateurs, certaines tables étaient manquantes 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)

13
Luke Schoen

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

set global max_allowed_packet=64*1024*1024;

ne nécessite pas non plus un redémarrage de MySQL. Notez que vous devez corriger votre fichier my.cnf comme indiqué dans les autres solutions:

[mysqld]
max_allowed_packet=64M

Et confirmez les modifications après le redémarrage de 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/arrêt qui risquent de ne pas survivre aux mises à jour et correctifs du système.

Comme demandé, j'ajoute ma propre réponse ici. Content de voir que ça marche!

11
razzed

J'ai eu le même problème mais la modification de max_allowed_packet dans le fichier my.ini/my.cnf sous [mysqld] a rendu l'astuce difficile.

ajouter une ligne

max_allowed_packet=500M

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

11
Sathish D

La solution augmente les valeurs en fonction des paramètres wait_timeout et connect_timeout dans votre fichier d'options, sous la balise [mysqld]. 

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 comprenez 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
8
RGA

Quelques choses pourraient se passer ici; 

  • Votre INSERT est longue et le client est en train de se déconnecter. Lorsqu'il se reconnecte, il ne sélectionne pas de base de données, d'où l'erreur. Une option consiste ici à exécuter votre fichier de commandes à partir de la ligne de commande et à sélectionner la base de données dans les arguments, comme suit;

$ mysql nom_base <source.sql

  • Une autre consiste à exécuter votre commande via php ou 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.
6
Chris Henry

Pour plus d'informations à ce sujet, reportez-vous à http://dev.mysql.com/doc/refman/5.5/en/gone-away.html Ou http: // dev.mysql.com/doc/refman/5.1/en/gone-away.html selon les cas.

3
Sean

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

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Et le mysqld fonctionne également correctement.Alors au début, je ne peux pas comprendre ce qui ne va pas. Et environ 5 minutes plus tard, le résultat de ndb_mgm ne montre aucun nœud de données en fonctionnement. Ensuite, je réalise le problème. Essayez donc de redémarrer tous les nœuds de données, puis le serveur mysql est de retour et tout va bien. 

Mais une chose m'est bizarre, après que j'ai perdu le serveur mysql pour certaines requêtes, quand j'utilise cmd comme 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. 

2
zhihong

Il s’agit plus d’un problème rare, mais j’ai vu cela si une personne a copié le répertoire/var/lib/mysql en entier comme moyen de migrer sa base de données vers un autre serveur. Cela ne fonctionne pas parce 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 à copier également les fichiers/var/log/mysql.

0
Areeb Soo Yasir

Pour Amazon RDS (c'est mon cas), vous pouvez remplacer la valeur du paramètre max_allowed_packet par une valeur numérique exprimée en octets, ce qui est logique pour les données les plus volumineuses d'une insertion (par exemple, si le max_allowed_packet à 64M = 67108864), dans un parameter-group nouveau ou existant. Appliquez ensuite ce groupe de paramètres à votre instance MySQL (vous devrez peut-être redémarrer l'instance).

0
SebaGra

S'il s'agit de se reconnecter et d'obtenir l'ID de connexion 2, le serveur est presque définitivement tombé en panne.

Contactez l'administrateur du serveur et demandez-leur 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 a commis une grosse erreur opérationnelle, telle que l'attribution de tailles de mémoire tampon supérieures aux limites d'espace adresse 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.

0
MarkR