Erreur Pylons - 'Le serveur MySQL est parti'

Question

[J'espère que ce n'est pas trop obscur & hellip; Je vais demander au newsgroup si personne ne sait ici]

J'utilise Pylons (un framework python) pour servir une application web simple, mais il semble mourir de temps en temps, avec ceci dans le journal des erreurs: (2006, 'MySQL server has gone away') J'ai fait un peu de vérification, et j'ai vu que c'était parce que les connexions à MySQL n'étaient pas renouvelées. Cela ne devrait pas être un problème, car le sqlalchemy.pool_recycle dans le fichier de configuration devrait automatiquement le garder en vie. La valeur par défaut était 3600, mais j'ai renvoyé le numéro à 1800 à cause de ce problème. Il a aidé un peu, mais 3600devrait bien être bien selon les docs. Les erreurs se produisent encore semi-régulièrement. Je ne veux pas trop l'abaisser et DOS ma propre base de données :).

Peut-être que quelque chose dans ma config MySQL est maladroit? Je ne sais pas où regarder 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 se trouve que j'ai eu une erreur de configuration simple. Mon fichier ini lecture:

sqlalchemy.default.url = [connection string here] 
sqlalchemy.pool_recycle = 1800 

Le problème est que mon dossier environment.py a déclaré que le moteur ne ferait que les clés de carte avec le préfixe: sqlalchemy.default donc pool_recycle a été ignoré.

La solution est de changer simplement la deuxième ligne dans le ini à:

sqlalchemy.default.pool_recycle = 1800 

Answer 2

Vous pouvez 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, les valeurs par défaut sont 28800 (MySQL tue les connexions après 8 heures), mais peut-être que la configuration par défaut de votre plateforme est différente ou que celle qui administre le serveur a configuré les choses différemment. AFAICT, pool_recycle ne maintient pas les connexions en vie, il les expire par lui-même avant que MySQL ne les tue. Je ne suis pas familier avec les pylônes, mais si les connexions sont provoquées 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 pensée: est-ce que vous réussissez à utiliser une connexion que les pylônes pensent avoir expirée?