MySQL: error 2006 — server has gone away

#Что означает ошибка

Ошибка 2006 «MySQL server has gone away» возникает, когда соединение закрылось: сервер перезапустился, истёк wait_timeout, запрос или пакет превысил max_allowed_packet, или соединение сброшено сетью/файрволом. Часто проявляется на длинных скриптах и импорте больших дампов.

Смотрите журнал ошибок MySQL: он покажет перезапуск или падение.

Затем проверьте параметры.

Соединение закрыто: тайм-аут, слишком большой пакет или падение сервера. Увеличьте wait_timeout и max_allowed_packet, проверьте логи.

#Причины и решения

#Пошаговое решение

1. Проверьте журнал MySQLНа сервере MySQL/MariaDB откройте системный терминал через SSH с правами администратора и посмотрите журнал службы: sudo journalctl -u mysql -n 100 --no-pager (для MariaDB — -u mariadb). Сопоставьте отметки времени с ERROR 2006: если сервер перезапускался или процесс был завершён из-за памяти, проблему нужно решать на сервере, а не увеличением сетевого таймаута клиента.
2. Проверьте max_allowed_packetВ phpMyAdmin → «SQL» либо в клиенте mysql выполните SHOW VARIABLES LIKE "max_allowed_packet"; и сравните значение с размером отправляемого INSERT/BLOB/результата. Увеличивайте параметр лишь при подтверждённом превышении и с учётом памяти сервера; значение 256 МБ не универсально. Настройку внесите в конфигурацию соответствующей версии MySQL и после согласованного перезапуска проверьте значение снова.
3. Проверьте wait_timeoutВ том же SQL-клиенте выполните SHOW VARIABLES LIKE "wait_timeout"; и SHOW VARIABLES LIKE "net_read_timeout";. Если соединение простаивает дольше wait_timeout, приложение должно проверять его состояние и устанавливать новое перед запросом. Увеличивать таймаут без анализа нагрузки нежелательно: простаивающие соединения продолжают занимать ресурсы.
4. Проверьте память и дискВ терминале сервера последовательно выполните df -h, df -i, free -h, затем journalctl -k -b | grep -Ei "out of memory|oom|killed process" с правами, достаточными для просмотра. Полный раздел, исчерпанные inode или убийство mysqld из-за OOM объясняют обрыв; освобождайте место и меняйте конфигурацию только после определения виновника и сохранения резервных копий.
5. Добавьте переподключение в приложенииВ приложении найдите участок, где соединение хранится между заданиями или долго не используется. Для чтения можно предусмотреть повторное подключение после ошибки 2006/2013; для INSERT/UPDATE/платёжных действий нельзя автоматически повторять запрос, пока не выяснено, успел ли сервер зафиксировать транзакцию. После изменения тестируйте отдельный сценарий, затем проверяйте отсутствие новых обрывов в журнале.

#Параметры

Выполните SHOW VARIABLES LIKE 'max_allowed_packet'; и SHOW VARIABLES LIKE 'wait_timeout';. Увеличьте пакет: в my.cnf [mysqld] max_allowed_packet=256M, [mysql] max_allowed_packet=256M, временно — SET GLOBAL max_allowed_packet=268435456;. Для длинных задач увеличьте wait_timeout и net_read_timeout. После изменения перезапустите сервер.

#Падения и память

Проверьте журнал: sudo journalctl -u mysql -n 100 или /var/log/mysql/error.log. Сообщения Out of memory / Killed process в dmesg говорят о срабатывании OOM-killer — снизьте innodb_buffer_pool_size или добавьте память. Следите за Uptime: SHOW GLOBAL STATUS LIKE 'Uptime'; — малое значение означает недавний перезапуск. Проверьте диск на заполнение (df -h).

#Клиент и сеть

В приложении добавьте переподключение при ошибке 2006 и 2013. Не держите долгие простаивающие соединения. Для импорта: mysql --max_allowed_packet=256M -u user -p db < dump.sql, дамп создавайте с --extended-insert=false или меньшими пакетами --net_buffer_length=16384. Проверьте файрвол и прокси, обрывающие неактивные соединения (idle timeout).