Ошибка MySQL server has gone away в Django 3.2 при потоках из представления

Разбираем, почему в Django 3.2 с MySQL фоновые потоки из представления приводят к ошибке «server has gone away», и даём безопасный синхронный подход под uWSGI+Nginx

Запуск записи в базу данных в фоновом потоке из представления Django 3.2 может показаться заманчивым, когда хочется мгновенно вернуть HTTP‑ответ. Но сочетание синхронных вызовов ORM с самодельными потоками регулярно приводит к ошибкам вроде MySQL «server has gone away». Ниже — короткое объяснение, почему так происходит, и какой безопасный, пригодный для продакшена подход уместен в этой ситуации.

Как воспроизвести проблему

Стек приложения: Django 3.2.x на Python 3, MySQL, развёрнуто через uWSGI + Nginx. Представление возвращает ответ сразу, а фоновый поток запускает работу ORM на уровне модели.

from django.http import HttpResponse
from django.db import models
import threading

# вспомогательная функция
def extract_request_params(request):
    return {}

# модель
class JobRecord(models.Model):
    create_username = models.CharField(max_length=50, default='system')
    update_username = models.CharField(max_length=50, default='system')

    @classmethod
    def perform(cls, params):
        # логика ORM
        pass

# представление
class OpsView:
    @classmethod
    def trigger_job(cls, request):
        payload = extract_request_params(request)
        payload['user'] = request.user
        worker = threading.Thread(target=JobRecord.perform, args=(payload,))
        worker.start()
        return HttpResponse("Task run success")

Симптом проявляется во время выполнения:

(2006, 'MySQL server has gone away')

Также была попытка принудительно управлять соединением внутри задачи:

from django.db import connection

class JobRecord(models.Model):
    create_username = models.CharField(max_length=50, default='system')
    update_username = models.CharField(max_length=50, default='system')

    @classmethod
    def perform(cls, params):
        connection.ensure_connection()
        # логика ORM
        # ...
        connection.close()

Но ошибка сохраняется.

Почему это не работает

ORM Django 3.2 — синхронная. Она не поддерживает выполнение ORM‑операций как асинхронной или отделённой фоновой задачи, запущенной прямо из обработчика запроса. Запуск самостоятельных потоков или процессов внутри представления выводит операции с базой из ожидаемой моделью исполнения Django, что приводит к нестабильной работе соединений и к описанной ошибке. Ручные вызовы ensure_connection или закрытие соединения в этом потоке не устраняют фундаментальное несоответствие.

Правильный подход

Безопасный подход прост: не запускайте отдельные потоки или процессы из представления. Держите операции с базой в обычном синхронном цикле запрос–ответ, под который рассчитан Django 3.2.

from django.http import HttpResponse
from django.db import models

# вспомогательная функция
def extract_request_params(request):
    return {}

# модель
class JobRecord(models.Model):
    create_username = models.CharField(max_length=50, default='system')
    update_username = models.CharField(max_length=50, default='system')

    @classmethod
    def perform(cls, params):
        # логика ORM
        pass

# представление без фонового потока
class OpsView:
    @classmethod
    def trigger_job(cls, request):
        payload = extract_request_params(request)
        payload['user'] = request.user
        JobRecord.perform(payload)
        return HttpResponse("Task run success")

Это убирает отделённый поток и выполняет операции ORM по поддерживаемому синхронному пути, устраняя сбои «MySQL server has gone away», вызванные использованием потоков.

Почему это важно

Фоновые потоки, запускаемые из представлений, в этой конфигурации ненадёжны. Они нарушают гарантии, на которые вы рассчитываете при совместной работе Django ORM и MySQL, и приводят к периодическим ошибкам соединения и потерянным операциям. Сохранение ORM на синхронном пути поддерживает надёжность и предсказуемость под uWSGI + Nginx в продакшене.

Замечания по стеку

Django 3.2 — довольно старая версия. Сама по себе эта ремарка проблему не решает, но стоит учитывать возраст целевого релиза.

Итоги

Если в вашем приложении на Django 3.2 при работе с базой в фоновом потоке, запущенном из представления, возникает «(2006, 'MySQL server has gone away')», решение — перестать запускать потоки или процессы из представлений. Выполняйте операции ORM синхронно в рамках цикла запроса. Это надёжный способ предотвратить временные разрывы соединения с MySQL и гарантировать корректное выполнение записей.