Сайт или CRM перестали сохранять данные, а в журнале появилась ошибка MySQL server has gone away. Она указывает на потерю соединения с базой, но сама по себе не объясняет причину: различать нужно простой подключения, слишком большой запрос и разрыв связи. До повторного запуска импорта или сохранения заказа выясните, могла ли первая попытка уже изменить данные.
Начните с трёх безопасных действий:
- Запишите время сбоя с часовым поясом, действие пользователя и точный текст ошибки. Для передачи подрядчику удалите из примера персональные данные, пароли и содержимое заказов.
- Отметьте, когда возникает ошибка: после паузы, на крупной порции импорта или одновременно в разных разделах. Уточните версию MySQL и используемый приложением драйвер у разработчика.
- Проверьте состояние исходной операции в системе учёта. Если результат записи неизвестен, приостановите её ручные повторы до разбора.
Это порядок диагностики для руководителя проекта и разработчика. Технические пояснения ниже сверены с документацией MySQL 8.0 и 8.4; настройки MariaDB, другой версии сервера и конкретного хостинга нужно проверять отдельно.
Дерево причин: что отличает один сбой от другого
Сопоставьте несколько наблюдений. Одного признака недостаточно, чтобы менять конфигурацию рабочего сервера.
| Наблюдение | Первая гипотеза | Что должно её подтвердить |
|---|---|---|
| Первый запрос после паузы падает, новое подключение работает | Старое соединение закрыто по таймауту | Связь сбоя с длительностью простоя и настройками именно этого подключения |
| Небольшая порция импорта проходит, крупная падает | Превышен допустимый размер пакета | Размер отправленного запроса и сообщение об ограничении на клиенте или сервере |
| Разные операции обрываются в одно время | Перезапуск MySQL или нарушение связи | Совпадение времени с событиями сервера, сети либо промежуточного прокси |
| Ошибка возникает у одного фонового обработчика | Неверное использование соединения в приложении | Повторное обращение к закрытому соединению или его совместное использование процессами |
Ошибка Too many connections относится к другому сценарию — исчерпанию доступных подключений. Увеличение их числа не является универсальным исправлением для server has gone away.
Ошибка после простоя: проверьте жизнь соединения
В MySQL параметр wait_timeout ограничивает ожидание активности на неинтерактивном соединении. Разработчику важно узнать значение в сессии приложения: оно может отличаться от глобального значения, которое видно в другом подключении. Это различие описано в MySQL Reference Manual, разделе Server System Variables.
Сравните паузу перед ошибкой с этим ограничением и временем хранения подключения в пуле — наборе соединений, которые приложение использует повторно. Если между приложением и базой есть прокси, отдельно проверьте его таймаут. Успешный запрос из консоли не доказывает исправность давно открытого подключения фоновой задачи.
На копии проекта воспроизведите паузу и последующее безопасное чтение. Если причина подтверждена, разработчик может изменить управление соединениями: не возвращать заведомо закрытое подключение в работу, создавать новое перед следующей независимой операцией. Простое повышение времени ожидания не устраняет ошибку в обращении с соединением.
Учебный пример: обработчик открыл базу, долго готовил файл без запросов, затем начал импорт. Сбой первого запроса после паузы — повод проверить таймаут, но не доказательство: в тот же промежуток сервер мог перезапуститься.
Ошибка на крупном импорте: измерьте запрос
MySQL ограничивает размер пакета параметром max_allowed_packet. Ограничение есть на стороне сервера и клиента; при превышении соединение может закрыться. Пакет здесь — например, один отправленный SQL-запрос или одна строка результата, а не размер всего файла импорта. Эти условия описаны в разделе Packet Too Large документации MySQL 8.4.
Попросите разработчика измерить размер фактически отправляемой порции, не сохраняя её конфиденциальное содержимое в отчёт. Затем сравните одинаковые обезличенные данные при разном размере порций на тестовой копии. Прохождение меньшей порции — диагностический признак, который нужно сопоставить с лимитами и журналом ошибки.
Исправление выбирают после измерения: уменьшить порцию либо обоснованно изменить ограничения. Если одна запись сама превышает предел, деление общего списка на части не поможет. После изменения нужно проверить полноту импорта: все ожидаемые записи обработаны, пропусков и повторов нет.
Не поднимайте одновременно все лимиты и таймауты. Иначе будет трудно установить, какое изменение помогло и можно ли безопасно оставить его в работе.
Общий обрыв: сопоставьте журналы и перезапуски
Если размер запроса и простой не объясняют сбой, сравните время ошибок приложения с журналом MySQL и событиями инфраструктуры. Проверяйте перезапуск базы, принудительное завершение соединения и разрыв сетевого пути. Документация MySQL «MySQL server has gone away» перечисляет такие причины отдельно: текст ошибки не позволяет выбрать одну из них без дополнительных данных.
При подтверждённом перезапуске выясняют его причину, а не ограничиваются повторным подключением. Если сервер продолжал работать, администратор проверяет путь от того узла, где выполняется приложение. Проверка базы с ноутбука по другому маршруту не заменяет этот шаг.
Когда сбой затрагивает только один обработчик, разработчик проверяет, не использует ли он уже закрытое соединение. Для дочерних процессов нужно также исключить совместное использование одного подключения. В рабочем проекте не стоит специально обрывать сеть или завершать процессы базы ради опыта — такие проверки проводят в изолированной среде.
Можно ли повторить запись после переподключения
Новое соединение не продолжает прежнюю транзакцию. Документация MySQL C API об автоматическом переподключении предупреждает о потере состояния сессии, включая активную транзакцию и временные таблицы. Поведение конкретного драйвера нужно сверить с его документацией; рассчитывать на незаметный автоматический повтор нельзя.
Для транзакционных таблиц, например InnoDB, COMMIT фиксирует изменения. Если приложение отправило фиксацию, но не получило ответ, из одного сообщения о разрыве нельзя заключить, что запись отсутствует. Практический вывод: перед повтором требуется проверка результата исходной операции.
Разработчик сопоставляет её идентификатор, состояние в базе и связанные действия в CRM или другой системе. Даже отсутствие записи при первой проверке не всегда разрешает немедленный повтор: прежняя серверная сессия ещё может выполнять работу, пока сервер не обнаружил разрыв. Неопределённый исход нужно разбирать отдельно.
Подробный сценарий защиты заказа от повторного эффекта разобран в статье о повторной отправке после таймаута. Здесь критерий тот же: восстановление связи должно сохранять корректность данных.
Как воспроизвести сбой и принять исправление
Подготовьте копию с той же версией базы и драйвера, обезличенными данными и возможностью отката. Отключите реальные платежи, рассылки и обмен с рабочими системами. Сначала воспроизведите исходный сбой, затем меняйте по одному условию.
В протокол приёмки включите:
- Простой: чтение после паузы, которая раньше приводила к ошибке, завершается корректно; приложение управляет закрытым подключением предсказуемо.
- Размер: согласованный объём импорта проходит полностью; слишком большая порция получает понятный контролируемый отказ без бесконечных повторов.
- Восстановление связи: после тестового разрыва обработчик возобновляет работу по согласованному правилу.
- Запись: одна исходная операция даёт один ожидаемый результат, без потерянных данных и повторного побочного действия.
- Наблюдение после выпуска: команда отслеживает повторение ошибки, завершение фоновых задач и целостность результатов в согласованном окне, которое включает прежние условия сбоя.
Зафиксируйте версию изменения, ожидаемый и фактический результат каждого опыта. Одной успешно открывшейся страницы недостаточно: она могла использовать новое соединение и не затронуть проблемный импорт.
Когда нужна помощь с рабочим проектом
Если ваша команда видит журналы, управляет кодом и может воспроизвести сбой на копии, она может пройти эти проверки самостоятельно. Внешняя помощь уместна, когда неизвестно устройство старого обработчика, нет ясности с результатом записи или проблема затрагивает сайт и несколько интеграций.
OpenStart занимается исправлением ошибок и сопровождением сайтов и интеграций. Порядок начала работ описан на странице поддержки сайта: сначала уточняются задача, объём и критерии приёмки. Для первого обсуждения достаточно симптома, времени сбоя, версии базы и обезличенного примера; пароли и полные журналы в публичной форме не нужны.