(2006, 'Le serveur MySQL est parti') dans WSGI django

J'ai un MySQL parti avec Django sous WSGI. J'ai trouvé des entrées pour ce problème sur stackoverflow, mais rien avec Django spécifiquement. Google n'aide pas, sauf pour les solutions de contournement (comme interroger le site Web de temps en temps, ou augmenter le délai d'expiration de la base de données). Rien de définitif. Techniquement, Django et/ou MySQLdb (j'utilise le dernier 1.2.3c1) devraient tenter une reconnexion si le serveur pendu la connexion, mais cela n'arrive pas. Comment puis-je résoudre ce problème sans solutions de contournement?(2006, 'Le serveur MySQL est parti') dans WSGI django

Source

2010-04-06 Stefano Borini

Le serveur Web et MySQL sont-ils sur le même ordinateur? Si ce n'est pas le cas, plus ils sont proches, moins il est probable qu'un problème de réseau entraînera le départ du serveur. – lexu

@lexu oui ils sont. –

sélectionnez la version(); afficher la liste de processus; afficher des variables comme '% max%; Collez la sortie: – iddqd

show variables like 'wait_timeout';

c'est le réglage rejettera les « mysql gone away » erreur
réglée à une valeur très importante pour l'empêcher « gone away »
simple ou re-ping la connexion mysql après période

Source

2010-11-10 16:08:03 ajreal

Eh bien, j'ai maintenant changé de travail, donc je ne peux pas le tester, mais j'espère que c'est correct :) –

Vous pouvez créer middleware ping() la connexion MySQL (qui reconnecté si elle a expiré) avant de traiter la vue
Vous pouvez également ajouter un intergiciel pour intercepter l'exception, reconnecter et réessayer la vue (je pense que je préférerais que la solution ci-dessus soit plus simple, mais elle devrait techniquement fonctionner et être performante si les délais d'attente sont rares. Cela suppose également une vue échoué n'a pas d'effets secondaires, ce qui est une propriété souhaitable, mais il peut être difficile à faire, surtout si vous écrivez à un système de fichiers ainsi qu'un db dans votre vue.)

Source

2012-03-14 12:54:01 Eloff

développeurs de Django ont donné une réponse courte pour toutes ces questions dans https://code.djangoproject.com/ticket/21597#comment:29

Resolution set to wontfix

Actually this is the intended behavior after #15119. See that ticket for the rationale.

If you hit this problem and don't want to understand what's going on, don't reopen this ticket, just do this:

RECOMMENDED SOLUTION: close the connection with from django.db import connection; connection.close() when you know that your program is going to be idle for a long time.

CRAPPY SOLUTION: increase wait_timeout so it's longer than the maximum idle time of your program.

In this context, idle time is the time between two successive database queries.

Source

2015-09-24 15:48:33

(2006, 'Le serveur MySQL est parti') dans WSGI django

Répondre

Questions connexes