Erreur de pylônes – « Le serveur MySQL a disparu »
Question
J'utilise Pylons (un framework python) pour servir une application Web simple, mais elle semble mourir de temps en temps, avec ceci dans le journal des erreurs : (2006, 'MySQL server has gone away')
J'ai fait quelques vérifications et j'ai vu que c'était parce que les connexions à MySQL n'étaient pas renouvelées.Cela ne devrait cependant pas poser de problème, car le sqlalchemy.pool_recycle
dans le fichier de configuration devrait automatiquement le maintenir en vie.La valeur par défaut était 3600
, mais je l'ai rappelé à 1800
à cause de ce problème.Ça a aidé un peu, mais 3600
devrait tout va bien selon la documentation.Les erreurs se produisent encore de manière semi-régulière.Je ne veux pas trop le baisser et DOS ma propre base de données :).
Peut-être que quelque chose dans ma configuration MySQL est loufoque ?Je ne sais pas où chercher exactement.
Autres détails pertinents :
Python 2.5
Pylons: 0.9.6.2 (w/ sql_alchemy)
MySQL: 5.0.51
La solution
Je pense que je l'ai réparé.Il s'avère que j'ai eu une simple erreur de configuration.Mon fichier ini disait :
sqlalchemy.default.url = [connection string here]
sqlalchemy.pool_recycle = 1800
Le problème est que mon environment.py
fichier a déclaré que le moteur mapperait uniquement les clés avec le préfixe : sqlalchemy.default
donc pool_recycle
a été ignoré.
La solution est simplement de changer la deuxième ligne de l'ini en :
sqlalchemy.default.pool_recycle = 1800
Autres conseils
Vous voudrez peut-être vérifier les variables de délai d'attente de MySQL :
show variables like '%timeout%';
Vous êtes probablement intéressé par wait_timeout
(moins probable mais possible : interactive_timeout
).Sur Debian et Ubuntu, la valeur par défaut est 28800 (MySQL tue les connexions après 8 heures), mais peut-être que la valeur par défaut de votre plate-forme est différente ou que celui qui administre le serveur a configuré les choses différemment.
AFAICT, pool_recycle
ne maintient pas réellement les connexions actives, il les fait expirer d'elles-mêmes avant que MySQL ne les tue.Je ne suis pas familier avec les pylônes, mais si les connexions effectuent un travail par intermittence, SELECT 1;
est une option qui les maintiendra en vie au prix d’une charge de serveur pratiquement nulle et d’un trafic réseau minimal.Une dernière réflexion :parvenez-vous d'une manière ou d'une autre à utiliser une connexion dont les pylônes pensent qu'elle a expiré ?