Code d'erreur: 2013. Connexion perdue au serveur MySQL pendant la requête

J'ai reçu le code d'erreur: 2013. Perte de connexion au serveur MySQL lors d'une erreur de requête lorsque j'ai essayé d'ajouter un index à une table à l'aide de MySQL Workbench. J'ai également remarqué qu'il apparaît chaque fois que j'exécute une longue requête.

Est-il possible d'augmenter la valeur du délai d'attente?

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

Pour moi, c'était sous Édition → Préférences → Éditeur SQL → Délai de lecture de la connexion au SGBD (en secondes): 600

Modification de la valeur à 6000.

Également des lignes de limite non cochées car mettre une limite à chaque fois que je veux rechercher l'ensemble de données devient fastidieux.

Démarrez le serveur DB avec l'option comandline net_read_timeout / wait_timeoutet une valeur appropriée (en secondes) - par exemple: --net_read_timeout=100.

Pour référence voir ici et ici .

Si votre requête contient des données d'objets blob, ce problème peut être résolu en appliquant une my.inimodification 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 n'est pas un multiple de 1024K, elle sera automatiquement arrondie au multiple de 1024K le plus proche.

Alors que le thread référencé concerne l'erreur MySQL 2006 , la définition max_allowed_packetde 1M à 16M a corrigé l'erreur 2013 qui s'est présentée lors de l'exécution d'une longue requête.

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

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

SET @@local.net_read_timeout=360;

Avertissement: les éléments suivants ne fonctionneront pas lorsque vous l'appliquez en connexion à distance:

SET @@global.net_read_timeout=360;

Il y a trois causes probables à 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 la requête» se produit lorsque des millions de lignes sont envoyées dans le cadre d'une ou plusieurs requêtes.
3. Plus rarement, cela peut se produire lorsque le client tente la connexion initiale au serveur

Pour plus de détails, lisez >>

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;

Merci, ça a marché. Mais avec les mises à jour mysqldb, la configuration est devenue:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

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

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

Exécutez la commande ci-dessous à partir de votre shell:

sudo mysql_upgrade -u root -p

Je sais que c'est 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.

Changez le temps de "lecture" dans Édition-> Préférences-> Éditeur SQL-> Session MySQL

Essayez de décocher les lignes de limite dans Édition → Préférences → Requêtes SQL

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

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

Mon mysqldump contenait au moins un INSERT qui était trop gros pour que mysql puisse être calculé. Vous pouvez afficher 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
• créer un vidage avec --skip-extended-insert , par insert une ligne est utilisée -> bien que ces vidages soient beaucoup plus agréables à lire, cela ne convient pas aux gros vidages> 1 Go car il a tendance à être très lent
• créer un vidage avec des insertions étendues (qui est la valeur par défaut) mais limiter la net-buffer_length, par exemple avec --net-buffer_length NR_OF_BYTESoù NR_OF_BYTES est plus petit que net_buffer_length du serveur -> Je pense que c'est la meilleure solution, bien que plus lent aucun 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

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

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 vous aidera.

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

A eu ce problème lorsque innodb_buffer_pool_size a été défini trop près de la mémoire physique sans un fichier d'échange configuré. MySQL recommande pour un serveur spécifique à la base de données de définir innodb_buffer_pool_size à un maximum d'environ 80% de la mémoire physique , je l'avais réglé à environ 90%, le noyau tuait le processus mysql. Déplacé innodb_buffer_pool_size à environ 80% et cela a résolu le problème.

Dans mon cas, la définition de l'intervalle de délai de connexion sur 6000 ou quelque chose de plus n'a pas fonctionné.

Je viens de faire ce que l’établi dit que je peux faire.

Temps maximal que la requête peut prendre pour renvoyer des données à partir du SGBD.Set 0 pour ignorer le délai de lecture.

Sur les préférences Mac -> Éditeur SQL -> Aller à la session MySQL -> définir l'intervalle de délai de lecture de la connexion à 0.

Et ça marche 😄

J'ai fait face à ce même problème. Je crois que cela se produit lorsque vous avez des clés étrangères vers 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 trouvé que cela fonctionnait.

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

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

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

Accédez à Workbench Edit → Préférences → Éditeur SQL → Délai de lecture des connexions SGBD: jusqu'à 3000. L'erreur ne s'est plus produite.

Aller à:

Édition -> Préférences -> Éditeur SQL

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

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

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. J'ai dû permettre la Executecapacité sur la mysqltable. Après avoir autorisé cela, je n'avais plus de connexions perdues

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

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

J'ai rencontré cela lors de l'exécution d'un processus stocké qui créait de nombreuses lignes dans une table de la base de données. Je pouvais voir l'erreur venir juste après que le temps ait franchi la limite de 30 secondes.

J'ai essayé toutes les suggestions dans les autres réponses. Je suis sûr que certains ont aidé, cependant - ce qui a vraiment fait que cela fonctionnait pour moi était de passer à SequelPro depuis Workbench.

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

Si vous utilisez SQL Work Bench, vous pouvez essayer d'utiliser l'indexation, en ajoutant un index à vos tables, pour ajouter un index, cliquez sur le symbole de clé (clé) sur la table, cela devrait ouvrir la configuration de la table, ci-dessous , cliquez sur la vue d'index, saisissez 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 étape pour les autres clés primaires des autres tables.

Il semble y avoir une réponse manquante ici pour ceux qui utilisent SSH pour se connecter à leur base de données MySQL. Vous devez vérifier deux endroits et non un, comme le suggèrent d'autres réponses:

Édition du plan de travail → Préférences → Éditeur SQL → SGBD

Édition du plan de travail → Préférences → SSH → Délais

Mes délais d'expiration SSH par défaut ont été définis très bas et causant certains (mais apparemment pas tous) de mes problèmes de délai d'expiration. Après, n'oubliez pas de redémarrer MySQL Workbench!

Enfin, il peut être utile 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 faire un ensemble global si le redémarrage de mysql n'est pas une option.

J'espère que cela t'aides!

Trois choses à suivre et à s'assurer:

1. Si plusieurs requêtes montrent une perte de connexion?
2. comment vous utilisez set query dans MySQL?
3. comment supprimer + mettre à jour la requête simultanément?

Réponses:

1. Essayez toujours de supprimer le definer car MySQL crée son propre definer et si plusieurs tables impliquées pour la mise à jour essaient de faire une seule requête car parfois plusieurs requêtes montrent une perte de connexion
2. Toujours définir la valeur en haut mais après SUPPRIMER si sa condition n'implique pas la valeur SET.
3. Utilisez SUPPRIMER D'ABORD PUIS METTRE À JOUR SI LES DEUX OPÉRATIONS SONT EFFECTUÉES SUR DIFFÉRENTES TABLES

vérifier

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

J'espère que cela t'aides

Cela signifie généralement que vous avez des "incompatibilités avec la version actuelle de MySQL Server", voir mysql_upgrade. J'ai rencontré ce même problème et j'ai simplement dû exécuter:

mysql_upgrade --password La documentation indique que "mysql_upgrade doit être exécuté à chaque mise à niveau de MySQL".