Django, après la mise à niveau: MySQL server has gone away

J'ai l'exécution d'un processus d'arrière-plan rqworker qui exécute des tâches distinctes pour actualiser certaines données d'après des actions de l'utilisateur.

Je reçois toujours OperationalError: (2006, 'MySQL server has gone away')
s'il n'y avait aucune action de l'utilisateur pendant plus de wait_timeout secondes.
Même si j'ai mis CONN_MAX_AGE moins de MySQL wait_timeout.

Que je comprends, l'évolution de CONN_MAX_AGE pourrait aider si Django vérifié et à proximité de ses connexions automatiquement par ce délai. Mais Django 1.7.x vérifie avant et après chaque demande (voir django/db/init.py#L101-L112 ).

Comme décrit dans Django billet 15119, nous pouvons voir que Django était de faire un ping pour valider si la connexion était vivant avant l'exécution de chaque requête. Ce problème a été corrigé dans s'engager 282b2f4.

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

Donc mon rqworker processus a pour valider la connexion elle-même pour chaque nouvel emploi. (Remarque: si l'on fermer une connexion, puis Django va créer un nouveau).

Je vais utiliser Django, conformément à la demande de l'approche pour l'emploi et l'appel django.db.close_old_connections() avant et après chaque emploi. Et oui, CONN_MAX_AGE doit être inférieure à MySQL wait_timeout, parce que Django ne vérifie pas si MySQL server has gone away dans django.db.close_old_connections() méthode.

OriginalL'auteur ta2-1

Sur Django 1.9:
J'ai eu un cours de Django Shell exécute dans un unix écran laissé sans surveillance pendant plus de 48 heures.
Quand je suis revenu en arrière et a couru un <some_model>.objects.filter il jeta
OperationalError: (2006, 'MySQL server has gone away')

Un rapide import django.db; django.db.close_old_connections() a fait le tour pour moi.

Je n'arrivais pas à trouver de la documentation pour close_old_connections() sur Django Docs 1,9 cependant voici la lien direct à sa mise en œuvre dans Django base de Code sur Github

OriginalL'auteur Deep

Nous avons remarqué cela aussi. La réponse ci-dessus de réglage CONN_MAX_AGE à quelque chose de moins que MySQL /MariaDB est wait_timeout œuvres - pour le web.

Pour des tâches longues, cependant cela ne semble pas fonctionner. Au lieu de cela nous enveloppa et de fermer la connexion à chaque fois que l'une de nos tâches en cours d'exécution est exécuté.

Nous combinons ceci avec notre propre piscine. À prendre ou à laisser par défaut de Django a aucun contrôle - pas quelque chose que nous avons aimé dans la production. Nous avons mis un max de la piscine pour tuer le serveur avant qu'il tue la DB avec un trop grand nombre de connexions. L'utiliser comme un décorateur pour vos tâches:

@close_db_connection()
def task_do_something():
print 'Bonjour'

'''
Created on Dec 23, 2017

@author: Kevin
'''
from functools import wraps

def close_db_connection(ExceptionToCheck=Exception, raise_exception=False, notify=False):
    """Close the database connection when we're finished, django will have to get a new one..."""
    def deco_wrap(f):
        @wraps(f)
        def f_wrap(*args, **kwargs):
            try:
                return f(*args, **kwargs)
            except Exception as e:
                raise e
            finally:
                from django.db import connection; 
                connection.close();

        return f_wrap
    return deco_wrap

OriginalL'auteur Kevin Parker