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?
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.
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].
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: Ce qui suit ne fonctionnera pas si vous l’appliquez en connexion distante:
SET @@global.net_read_timeout=360;
Il y a trois causes probables pour ce message d'erreur
- 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
- Parfois, le formulaire «pendant l'interrogation» survient lorsque des millions de lignes sont envoyées dans le cadre d'une ou plusieurs interrogations.
- 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;
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.
Merci! Ca a marché . Mais avec les mises à jour de mysqldb la configuration est devenue
max_allowed_packet
net_write_timeout
net_read_timeout
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
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.
Changer le temps de lecture dans Edit-> Preferences-> SQL editor-> MySQL session
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.
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_BYTESoù 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
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.
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.
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.
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.
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.
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?
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.
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.
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
Vérifiez si les indexes sont en place en premier.
SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
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).
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!