Erreur MySQL 2006: le serveur mysql est parti

J'exécute un serveur à mon bureau pour traiter certains fichiers et rapporter les résultats à un serveur MySQL distant.

Le traitement des fichiers prend un certain temps et le processus se termine à mi-chemin avec l'erreur suivante:

2006, MySQL server has gone away

J'ai entendu parler du paramètre MySQL, wait_timeout , mais dois-je le changer sur le serveur de mon bureau ou sur le serveur MySQL distant?

Il peut être plus facile de vérifier la connexion et de la rétablir si nécessaire.

Voir PHP: mysqli_ping pour plus d'informations à ce sujet.

Je l'ai rencontré plusieurs fois et j'ai normalement trouvé que la réponse était un paramètre par défaut très bas max_allowed_packet.

L'augmentation de /etc/my.cnf(sous [mysqld]) à 8 ou 16M le corrige généralement. (La valeur par défaut dans MySql 5.7 est 4194304, qui est de 4 Mo.)

[mysqld]
max_allowed_packet=16M

Remarque: il suffit de créer la ligne si elle n'existe pas

Remarque: cela peut être défini sur votre serveur pendant son fonctionnement.

Utilisez set global max_allowed_packet=104857600. Cela le définit à 100 Mo.

J'ai eu le même problème mais en changeant max_allowed_packetle my.ini/my.cnffichier sous[mysqld] fait l'affaire.

ajouter une ligne

max_allowed_packet = 500M

maintenant restart the MySQL serviceune fois que vous avez terminé.

J'ai utilisé la commande suivante dans la ligne de commande MySQL pour restaurer une base de données MySQL d'une taille supérieure à 7 Go, et cela fonctionne.

set global max_allowed_packet=268435456;

Erreur: 2006 ( CR_SERVER_GONE_ERROR )

Message: le serveur MySQL est parti

En général, vous pouvez réessayer de vous connecter, puis refaire la requête pour résoudre ce problème - essayez 3-4 fois avant d'abandonner complètement.

Je suppose que vous utilisez PDO. Si tel est le cas, vous interceptez l'exception PDO, incrémentez un compteur, puis réessayez si le compteur est inférieur à un seuil.

Si vous avez une requête qui provoque un délai d'attente, vous pouvez définir cette variable en exécutant:

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

Où 300 est le nombre de secondes que vous pensez que la durée maximale de la requête pourrait prendre.

Plus d'informations sur la façon de traiter les problèmes de connexion Mysql.

EDIT: Deux autres paramètres que vous pouvez également utiliser sont net_write_timeoutet net_read_timeout.

Dans MAMP (version non-pro) j'ai ajouté

--max_allowed_packet=268435456

à ...\MAMP\bin\startMysql.sh

Crédits et plus de détails ici

Cette erreur est due à l'expiration de wait_timeout.

Allez simplement sur le serveur mysql vérifier son wait_timeout:

mysql> AFFICHER LES VARIABLES COMME 'wait_timeout'

mysql> set global wait_timeout = 600 # 10 minute ou délai d'attente maximum dont vous avez besoin

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

Il y a plusieurs causes à cette erreur.

Concernant MySQL / MariaDB:

• wait_timeout - Durée en secondes pendant laquelle le serveur attend qu'une connexion devienne active avant de la fermer.
• interactive_timeout - Durée en secondes pendant laquelle le serveur attend une connexion interactive.
• max_allowed_packet- Taille maximale en octets d'un paquet ou d'une chaîne générée / intermédiaire. Définissez la taille du BLOB le plus grand, par multiples de 1024.

Exemple de my.cnf :

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

Concernant le serveur:

• Votre serveur a une mémoire pleine - vérifiez les informations sur la RAM avec free -h

Concernant le cadre:

• Vérifiez les paramètres de votre framework. Django par exemple utiliser CONN_MAX_AGE(voir docs )

Comment le déboguer:

• Vérifiez les valeurs des variables MySQL / MariaDB.
  • avec sql: SHOW VARIABLES LIKE '%time%';
  • ligne de commande: mysqladmin variables
• Activez la verbosité pour les erreurs:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Consultez la documentation pour plus d'informations sur l'erreur

Sous Windows, les gars utilisant xampp doivent utiliser ce chemin xampp / mysql / bin / my.ini et changer max_allowed_packet (sous la section [mysqld]) à la taille de votre choix. par exemple

max_allowed_packet=8M

Encore une fois sur php.ini (xampp / php / php.ini), changez upload_max_filesize la taille choisie. par exemple

upload_max_filesize=8M

M'a donné un mal de tête pendant un certain temps jusqu'à ce que je découvre cela. J'espère que ça aide.

J'obtenais cette même erreur sur mon serveur DigitalOcean Ubuntu.

J'ai essayé de changer les paramètres max_allowed_packet et wait_timeout mais aucun d'eux ne l'a corrigé.

Il s'avère que mon serveur était à court de RAM. J'ai ajouté un fichier d'échange de 1 Go et cela a résolu mon problème.

Vérifiez votre mémoire avec free -hpour voir si c'est la cause.

C'était un problème de RAM pour moi.

J'avais le même problème même sur un serveur avec 12 cœurs de processeur et 32 ​​Go de RAM. J'ai fait plus de recherches et j'ai essayé de libérer de la RAM. Voici la commande que j'ai utilisée sur Ubuntu 14.04 pour libérer de la RAM:

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

Et, il a tout réparé. Je l'ai mis sous cron pour fonctionner toutes les heures.

crontab -e

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

Et, vous pouvez utiliser cette commande pour vérifier la quantité de RAM disponible disponible:

free -h

Et vous obtiendrez quelque chose comme ceci:

             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

Dans mon cas, c'était une faible valeur de open_files_limit variable, qui bloquait l'accès de mysqld aux fichiers de données.

Je l'ai vérifié avec:

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

Après avoir changé la variable en grande valeur, notre serveur était de nouveau en vie:

[mysqld]
open_files_limit = 100000

Si vous utilisez le WAMPSERVER 64 bits, veuillez rechercher plusieurs occurrences de max_allowed_packet car WAMP utilise la valeur définie sous [wampmysqld64] et non la valeur définie sous [mysqldump], ce qui pour moi était le problème, je mettais à jour la mauvaise. Définissez ceci sur quelque chose comme max_allowed_packet = 64M.

Espérons que cela aide les autres utilisateurs de Wampserver.

Cela indique généralement des problèmes de connexion au serveur MySQL ou des délais d'expiration. Peut généralement être résolu en modifiant wait_timeout et max_allowed_packet dans my.cnf ou similaire.

Je suggère ces valeurs:

wait_timeout = 28800

max_allowed_packet = 8M

Pour Vagrant Box, assurez-vous d'allouer suffisamment de mémoire à la boîte

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

Le scénario peu probable est que vous disposez d'un pare-feu entre le client et le serveur qui force la réinitialisation TCP dans la connexion.

J'ai eu ce problème et j'ai trouvé que notre pare-feu F5 d'entreprise était configuré pour mettre fin aux sessions inactives inactives pendant plus de 5 minutes.

Encore une fois, c'est le scénario improbable.

C'est toujours une bonne idée de vérifier les journaux du serveur Mysql, pour la raison pour laquelle il a disparu.

Cela vous le dira.

Si vous utilisez un serveur xampp:

Allez dans xampp -> mysql -> bin -> my.ini

Modifier le paramètre ci-dessous:

max_allowed_packet = 500M

innodb_log_file_size = 128M

Cela m'a beaucoup aidé :)

décommentez la ligne ci-dessous dans votre my.ini/my.cnf, cela divisera votre gros fichier en portion plus petite

# binary logging format - mixed recommended
# binlog_format=mixed

À

# binary logging format - mixed recommended
binlog_format=mixed

J'ai trouvé la solution à "# 2006 - Le serveur MySQL est parti" cette erreur. La solution consiste simplement à vérifier deux fichiers

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

Le chemin de ces fichiers dans Windows est

C:\wamp64\apps\phpmyadmin4.6.4

Dans ces deux fichiers, la valeur de ceci:

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

Dans mon cas, c'était:

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

changez-le en:

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

Assurez-vous dans les deux:

1. config.inc.php
2. fichiers config.sample.inc.php, il doit être «localhost».

Et dernier set:

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

Redémarrez ensuite Wampserver.

Pour modifier le nom d'utilisateur et le mot de passe phpmyadmin

Vous pouvez directement changer le nom d'utilisateur et le mot de passe de phpmyadmin via le fichier config.inc.php

Ces deux lignes

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

Ici, vous pouvez donner un nouveau nom d'utilisateur et un nouveau mot de passe. Après les modifications, enregistrez le fichier et redémarrez le serveur WAMP.

J'ai reçu le message d'erreur 2006 dans différents logiciels clients MySQL sur mon bureau Ubuntu. Il s'est avéré que ma version de pilote JDBC était trop ancienne.

Cela peut être dû à la taille de votre fichier .sql.

Si vous utilisez xampp. Allez dans le panneau de configuration de xampp -> Cliquez sur MySql config -> Open my.ini.

Augmentez la taille du paquet.

max_allowed_packet = 2M -> 10M

Il existe un moyen plus simple si vous utilisez XAMPP. Ouvrez le panneau de configuration XAMPP et cliquez sur le bouton de configuration dans la section mysql.

Maintenant, cliquez sur my.ini et il s'ouvrira dans l'éditeur. Mettez à jour le max_allowed_packet à votre taille requise.

Redémarrez ensuite le service mysql. Cliquez sur Arrêter sur le service Mysql, cliquez à nouveau sur Démarrer. Attendez quelques minutes.

Essayez ensuite d'exécuter à nouveau votre requête Mysql. J'espère que cela fonctionnera.

MAMP 5.3, vous ne trouverez pas my.cnf et les ajouter ne fonctionne pas car max_allowed_packet est stocké dans des variables.

Une solution peut être:

1. Accédez à http: // localhost / phpmyadmin
2. Accédez à l'onglet SQL
3. Exécutez SHOW VARIABLES et vérifiez les valeurs, si elles sont petites, exécutez-les avec de grandes valeurs

4. Exécutez la requête suivante, il a défini max_allowed_packet sur 7 Go:

   set global max_allowed_packet = 268435456;

Pour certains, vous devrez peut-être également augmenter les valeurs suivantes:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Pour les utilisateurs utilisant XAMPP, il y a 2 paramètres max_allowed_packet dans C: \ xampp \ mysql \ bin \ my.ini.

Cette erreur se produit essentiellement pour deux raisons.

1. Vous avez une RAM trop faible.
2. La connexion à la base de données est fermée lorsque vous essayez de vous connecter.

Vous pouvez essayer ce code ci-dessous.

# 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()

Il atténue l'erreur quelle qu'en soit la raison, en particulier pour la deuxième raison.

Si cela est dû à une faible RAM, vous devez soit augmenter l'efficacité de la connexion à la base de données à partir du code, de la configuration de la base de données, soit simplement augmenter la RAM.

Juste au cas où cela aiderait quelqu'un:

J'ai eu cette erreur lorsque j'ai ouvert et fermé des connexions dans une fonction qui serait appelée depuis plusieurs parties de l'application. Nous avons obtenu trop de connexions, nous avons donc pensé que ce serait une bonne idée de réutiliser la connexion existante ou de la jeter et d'en créer une nouvelle comme ceci:

  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 ($ base de données, $ hôte, $ utilisateur, $ mot de passe); } return self :: $ instance; } Eh bien, il s'avère que nous avons été un peu trop minutieux avec le massacre et que les processus faisant des choses importantes sur l'ancienne connexion n'ont jamais pu terminer leurs affaires. Nous avons donc abandonné ces lignes

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

et comme le matériel et la configuration de la machine le permettent, nous avons augmenté le nombre de connexions autorisées sur le serveur en ajoutant

max_connections = 500

à notre fichier de configuration. Cela a résolu notre problème pour l'instant et nous avons appris quelque chose sur la suppression des connexions mysql.

Si vous savez que vous vous déconnectez pendant un certain temps, vous pouvez fermer votre connexion, effectuer votre traitement, vous reconnecter et rédiger vos rapports.