L'établi MySQL laisse tomber la connexion au ralenti
J'utilise MySQL Workbench 6.3 sur mon OS X 10.9.5 pour gérer plusieurs bases de données cloud (hébergées sur Rackspace), et j'obtiens le numéro suivant:
Lorsqu'il est inactif pendant 5 minutes, les problèmes suivants se produisent:
- Je ne peux lancer aucune requête (erreur 2013: perte de connexion au serveur MySQL pendant la requête)
- en essayant de parcourir les tables sur ma base de données, je reçois des messages comme "les Tables ne pouvaient pas être récupérées", " les vues ne pouvaient pas être récupérée", et ainsi de suite
- en rafraîchissant le panneau de gauche, je reçois un "code D'erreur: 2006 MySQL server has gone away "
donc en gros, la connexion a disparu.
c'est vraiment ennuyeux car cela se produit après seulement 5 minutes d'inactivité. Je dois donc fermer la connexion et la rouvrir à chaque fois.
j'ai aussi essayé ceci: MySQL Workbench: Comment garder la connexion vivante , qui n'a rien changé. Dans mon onglet Préférences D'établi, j'ai la configuration suivante:
- connexion aux SGBD keep-alive intervalle (en secondes): 600
- temps de lecture de la connexion au SGBD (en secondes): 600
- connexion aux SGBD temps (en secondes): 60
notez que ce numéro arrive précisément après 5 minutes d'inactivité! si j'exécute deux requêtes dans un intervalle de 4'59 minutes il fonctionne parfaitement bien. Aussi mes collègues qui se connectent à la même base de données sur leur établi n'ont pas ce problème.
est-ce que quelqu'un a une solution pour ça?
7 réponses
allez à Edit - > Preferences - > SQL Editor et là vous verrez:
DBMS connection keep-alive interval (in seconds): 600
DBMS connection read time out (in seconds): 600
DBMS connection time out (in seconds): 60
l'intervalle de maintien de la connexion du SGBD signifie la fréquence à laquelle L'établi envoie une demande de maintien de la connexion au serveur.
depuis 5 minutes = = 300 secondes, établir la connexion au SGBD intervalle de maintien en vie < 300 (c.-à-d. G. 250)
signifie"envoyer une demande de maintien en vie toutes les 250 secondes". Cliquez sur OK.
alors quittez MySQL Workbench et relancez-le pour que les changements prennent effet.
si vous utilisez la méthode de connexion standard TCP/IP sur SSH, il peut également être utile de configurer SSH ServerAliveInterval.
ce bug existe dans toutes les versions de MySQL Workbench au-delà de 6.0 (actuellement 6.1, 6.2 et 6.3 ont le bug).
déclassement à MySQL Workbench 6.0.x semble le seul moyen de résoudre ce problème.
Télécharger MySQL Workbench 6.0.x: http://dev.mysql.com/downloads/workbench/6.0.html
FWIW: suite à la recommandation de Kosh, j'ai changé les paramètres comme suit et il semble avoir éliminé le problème sur WB 6.3 tournant sur Ubuntu 16:
DBMS connection keep-alive interval (in seconds): 60
DBMS connection read time out (in seconds): 60
DBMS connection time out (in seconds): 30
C'est peut-être exagéré, mais il fonctionne.
la réponse de Kosh Very n'a pas fonctionné pour moi donc j'ai trouvé une solution différente pour cela:
changement max_allowed_packet dans le "151900920 de fichier". (C:\ProgramData\MySQL\MySQL Serveur 5.6)
max_allowed_packet=16M
redémarrez maintenant le service MySQL une fois que vous avez terminé.
il m'a résolu en mettant tcp_keepalive_time à 120 secondes sur Ubuntu 14.04 hébergé sur Windows Azure
le keepalive TCP sur le balancier de charge Azure est de 240 secondes par défaut, ce qui peut le faire tomber en silence les connexions si le keepalive TCP sur vos systèmes Azure est supérieur à cette valeur. Vous devez définir tcp_keepalive_time à 120 pour améliorer ce problème.
- pour vérifier le tcp_keepalive_time
chat / proc/sys / net / ipv4 / tcp_keepalive_time
151980920"
7200 (par défaut 2 heures)
2.définir la valeur de 2 heures à 120 secondes.
sudo sysctl-w net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_time = 120
- revérifiez la valeur après avoir changé.
cat / proc/sys / net / ipv4 / tcp_keepalive_time
120
4.Définissez la valeur dans le fichier sysctl de rester la valeur même après le redémarrage.
vi/etc / sysctl.conf
appuyez sur i (pour insérer dans le fichier) net.ipv4.tcp_keepalive_time = 120 (ajouter cette ligne en bas du fichier) :wq(Enregistrer et quitter)
Kosh Très est la bonne réponse. Pour tous ceux qui n'ont pas pu le faire fonctionner, voici une autre solution:
où je dois modifier une table énorme (drop ou ajouter colonne ou tel), est d'exécuter la(Les) requête (s) par le terminal:
-
connecter :
mysql -u myusername -p -
on vous demandera le mot de passe
- Exécuter la longue prise de requête(s) dont vous avez besoin. Note: l'écriture d'une requête dans le terminal nécessite un point-virgule (;) pour chacune. Exemple:
ALTER TABLE mydb.mytable DROP COLUMN mycol;
cela m'a rendu fou pendant des mois. Mes connexions étaient à un serveur Hostgator. Je me connectais et je pouvais éditer une table pendant seulement 10 secondes environ après la connexion, puis je faisais, disons, une commit table et la table changerait en "lecture seule" avec un message de, "ne pouvait pas déterminer un identifiant de ligne unique (serveur MySQL est parti) ou "(connexion perdue au serveur MySQL pendant la requête).
la solution a été, comme d'autres suggestions ici, de réduire la keep-alive réglage. Dans mon cas, il a dû descendre à 10s (évidemment, Hostgator si assez avare avec leur bande passante!)
J'ai d'abord essayé de réduire SSH KeepAlive (sous Preferences/Others/Timeouts ) mais cela n'a pas fonctionné.
ce qui a fait l'affaire a été de réduire le DBMS connection keep-alive interval (sous Préférences/SQL Editor/MySQL Session ). J'ai dû descendre jusqu'à 10s jusqu'à ce que la connexion reste. stable. Votre hôte pourrait être différent.
enfin, plus de "rafraîchir tout", attendre, faire quelque chose, rincer et répéter.