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

Answer 1

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

Answer 2

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é ?