web-dev-qa-db-fra.com

Code d'erreur: 2013. Connexion perdue au serveur MySQL lors d'une requête

J'ai obtenu le Code d'erreur: 2013. Connexion perdue au serveur MySQL lors de l'erreur query lorsque j'ai tenté d'ajouter un index à une table à l'aide de MySQL Workbench. J'ai aussi remarqué qu'il apparaît chaque fois que je lance une longue requête. 

Y a-t-il un moyen d'augmenter la valeur du délai d'attente?

178
user836026

Les nouvelles versions de MySQL WorkBench ont une option pour modifier les délais d'expiration spécifiques.

Pour moi, cela se trouvait sous Édition → Préférences → Editeur SQL → Délai de lecture de la connexion à un SGBD (en secondes): 600

Changé la valeur à 6000.

Également, les lignes de limites non vérifiées, car mettre une limite à chaque fois que je veux effectuer une recherche dans l'ensemble du jeu de données devient fastidieux. 

342

Démarrez le serveur de base de données avec l'option de ligne de commande net_read_timeout/wait_timeout et une valeur appropriée (en secondes) - par exemple: --net_read_timeout=100.

Pour référence voir ici et ici .

28
Yahia

Si votre requête contient des données blob, vous pouvez résoudre ce problème en appliquant un my.ini change comme proposé dans cette réponse :

[mysqld]
max_allowed_packet=16M

Par défaut, ce sera 1M (la valeur maximale autorisée est 1024M). Si la valeur fournie ne correspond pas à un multiple de 1024 Ko, elle sera automatiquement arrondie au multiple de 1024 Ko le plus proche.

Alors que le thread référencé concerne l'erreur MySQL 2006, définir le max_allowed_packet de 1M à 16M did corrige l'erreur 2013 qui s'est produite lors d'une requête longue.

Pour les utilisateurs de WAMP: vous trouverez le drapeau dans la section [wampmysqld].

16
Harti

Ajoutez ce qui suit dans le fichier/etc/mysql/cnf:

innodb_buffer_pool_size = 64M

exemple:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M
14
MysqlMan
SET @@local.net_read_timeout=360;

Avertissement: Ce qui suit ne fonctionnera pas si vous l’appliquez en connexion distante:

SET @@global.net_read_timeout=360;
10
user1313024

Il y a trois causes probables pour ce message d'erreur

  1. Habituellement, cela indique un problème de connectivité réseau et vous devez vérifier l'état de votre réseau si cette erreur se produit fréquemment
  2. Parfois, le formulaire «pendant l'interrogation» survient lorsque des millions de lignes sont envoyées dans le cadre d'une ou plusieurs interrogations.
  3. Plus rarement, cela peut arriver lorsque le client tente la connexion initiale au serveur

Pour plus de détails lire >>

Cause 2: 

SET GLOBAL interactive_timeout=60;

de sa valeur par défaut de 30 secondes à 60 secondes ou plus

Cause 3:

SET GLOBAL connect_timeout=60;
9
Nanhe Kumar

Vous devez définir les propriétés 'interactive_timeout' et 'wait_timeout' dans le fichier de configuration mysql sur les valeurs dont vous avez besoin.

8
Maksym Polshcha

Merci! Ca a marché . Mais avec les mises à jour de mysqldb la configuration est devenue

max_allowed_packet

net_write_timeout

net_read_timeout

doc mysql

8
user2286136

Effectuez simplement une mise à niveau de MySQL qui reconstruira le moteur innoDB avec la reconstruction de nombreuses tables nécessaires au bon fonctionnement de MySQL, telles que performance_schema, information_schema, etc.

Émettez la commande ci-dessous à partir de votre shell:

Sudo mysql_upgrade -u root -p
7
Shoaib Khan

Je connais son vieux mais sur mac 

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.
4
Aamir Mahmood

Changer le temps de lecture dans Edit-> Preferences-> SQL editor-> MySQL session

4
user6234739

Essayez de décocher la limite du nombre de lignes dans Édition → Préférences → Requêtes SQL. 

car vous devez définir les propriétés 'interactive_timeout' et 'wait_timeout' dans le fichier de configuration mysql sur les valeurs dont vous avez besoin.

3
user2586714

Si vous rencontrez ce problème lors de la restauration d'un gros fichier de vidage et que vous pouvez exclure le problème selon lequel cela a quelque chose à voir avec le réseau (par exemple, une exécution sur localhost), ma solution pourrait être utile.

Mon mysqldump contenait au moins un INSERT trop grand pour que mysql puisse le calculer. Vous pouvez visualiser cette variable en tapant show variables like "net_buffer_length"; dans votre mysql-cli . Vous avez trois possibilités:

  • augmenter net_buffer_length dans mysql -> cela nécessiterait un redémarrage du serveur
  • create dump avec --skip-extended-insert, par insertion, une ligne est utilisée -> bien que ces dumps soient beaucoup plus agréables à lire, cela ne convient pas aux gros dumps> 1 Go, car il a tendance à être très lent
  • créez un cliché avec des insertions étendues (ce qui est la valeur par défaut), mais limitez par exemple net-buffer_length. avec --net-buffer_length NR_OF_BYTES où NR_OF_BYTES est plus petit que net_buffer_length -> Je pense que c'est la meilleure solution, bien qu'aucun ralentissement du redémarrage du serveur ne soit nécessaire.

J'ai utilisé la commande mysqldump suivante: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile 

3
Matt V

Si toutes les autres solutions ici échouent, vérifiez votre syslog (/ var/log/syslog ou similaire) pour voir si votre serveur manque de mémoire pendant la requête.

Vous aviez ce problème lorsque innodb_buffer_pool_size était trop proche de la mémoire physique sans qu'un fichier d'échange ne soit configuré. MySQL recommande de configurer innodb_buffer_pool_size sur un serveur spécifique à environ 80% de la mémoire physique . Innodb_buffer_pool_size a été ramené à environ 80%, ce qui a résolu le problème.

2
A_funs

J'ai eu le même problème lors du chargement d'un fichier .csv . Converti le fichier en.

En utilisant la commande ci-dessous, je parviens à contourner ce problème.

mysql -u <user> -p -D <DB name> < file.sql

J'espère que cela aiderait.

2
Vinod Amarathunga

J'ai fait face au même problème. Je crois que cela arrive quand vous avez des clés étrangères dans des tables plus grandes (ce qui prend du temps).

J'ai essayé d'exécuter à nouveau l'instruction create table sans les déclarations de clé étrangère et j'ai constaté que cela fonctionnait. 

Ensuite, après avoir créé la table, j'ai ajouté la contrainte de clé étrangère à l'aide de la requête ALTER TABLE.

J'espère que cela aidera quelqu'un.

1
Nimeshka Srimal

Cela m'est arrivé parce que mon innodb_buffer_pool_size était défini pour être plus grand que la taille RAM disponible sur le serveur. Les choses ont été interrompues à cause de cela et il génère cette erreur. Le correctif consiste à mettre à jour my.cnf avec le paramètre correct pour innodb_buffer_pool_size.

1
Phyllis Sutherland

Si vous utilisez SQL Work Bench, vous pouvez utiliser l'indexation, en ajoutant un index à vos tables, pour ajouter un index, cliquez sur le symbole clé (clé) de la table, cela devrait ouvrir la configuration de la table ci-dessous. Cliquez sur la vue d’index, tapez un nom d’index et définissez le type sur Index. Dans les colonnes d’index, sélectionnez la colonne principale de votre table.

Faites la même chose pour d'autres clés primaires sur d'autres tables.

0
Matthew E

Je me suis heurté à cette situation tout en exécutant un processus stocké qui créait de nombreuses lignes dans une table de la base de données . Je pouvais voir que l'erreur venait juste après que la limite de 30 secondes ait été atteinte.

J'ai essayé toutes les suggestions dans les autres réponses. Je suis certain que certaines de ces solutions ont aidé, cependant - ce qui a vraiment fonctionné pour moi a été de passer de Seback à SequelPro.

Je suppose que c’était une connexion côté client que je ne pouvais pas repérer dans Workbench . Peut-être que cela aiderait aussi quelqu'un d’autre?

0
RN.

Sélectionnez Edition → Préférences → Editeur SQL → Délai de lecture des connexions aux SGBD: jusqu'à 3 000 . L'erreur ne s'est plus produite.

0
Kairat Koibagarov

Il s'avère que notre règle de pare-feu bloquait ma connexion à MYSQL. Une fois la stratégie de pare-feu levée pour autoriser la connexion, j'ai pu importer le schéma avec succès.

0
wuro

J'ai eu le même problème - mais pour moi, la solution était un utilisateur de base de données avec des autorisations trop strictes ... Je devais autoriser la possibilité Execute sur la table mysql. Après avoir autorisé le fait que je ne perdais plus de connexions

0
naabster

Vérifiez si les indexes sont en place en premier.

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
0
Gayan Dasanayake

Aller à:

Edition -> Préférences -> Editeur SQL

Dans celui-ci, vous pouvez voir trois champs dans le groupe "Session MySQL", où vous pouvez maintenant définir les nouveaux intervalles de connexion (en secondes).

0
Max

Il semble qu'il manque une réponse ici pour ceux qui utilisent SSH pour se connecter à leur base de données MySQL. Vous devez vérifier deux endroits et non pas 1 comme suggéré par d'autres réponses:

Workbench Edition → Préférences → Editeur SQL → SGBD

Workbench Edition → Préférences → SSH → Délais d'expiration

Mes délais d’exécution SSH par défaut ont été définis très bas et sont à l’origine de certains problèmes (mais pas tous apparemment). Après, n'oubliez pas de redémarrer MySQL Workbench!

Enfin, il peut être intéressant de contacter votre administrateur de base de données et de lui demander d'augmenter les propriétés wait_timeout et interactive_timeout dans mysql lui-même via my.conf + mysql restart ou de créer un ensemble global si redémarrer mysql n'est pas une option.

J'espère que cela t'aides!

0
ThatOneGuy