Содержание
- Ошибка 2006: MySQL server has gone away
- Как исправить MySQL server has gone away
- 1. Истекло время ожидания
- 2. Слишком большой пакет
- 3. Сервер неверно проинициализирован
- Выводы
- Частые вопросы
- Ошибки базы данных
- MySQL Server Has Gone Away — как пофиксить
- Таймаут соединения
- Большой или некорректный пакет
- Самое главное
Ошибка 2006: MySQL server has gone away
Эта ошибка означает, что MySQL сервер запущен, но он отказывает вам в соединении. Это может произойти по нескольким причинам. Самых основных и часто встречающихся причин три: сервер перегружен, и у вас истекло время ожидания ответа, ваш клиент отправил слишком большой пакет или сервер был не до конца проинициализирован.
В этой небольшой статье мы рассмотрим более подробно, почему возникает ошибка 2006: MySQL server has gone away, а также — как её исправить.
Как исправить MySQL server has gone away
Такую ошибку вы можете увидеть во время подключения к базе данных с помощью PHP, консольного клиента или, например, в PhpMyAdmin:
1. Истекло время ожидания
Как я уже писал выше, одной из причин может быть таймаут ожидания соединения. Возможно, сервер баз данных перегружен и не успевает обрабатывать все соединения. Вы можете подключиться к серверу с помощью консольного клиента, если вам это удастся, и попытаться выполнить какой-либо запрос, чтобы понять, действительно ли запросы выполняются слишком долго. Если это так, можно оптимизировать производительность MySQL с помощью скрипта MySQLTuner.
В большинстве случаев надо увеличить размер пула движка InnoDB с помощью параметра innodb_buffer_pool_size. Какое значение лучше поставить, можно узнать с помощью указанного выше скрипта. Например, 800 мегабайт:
sudo vi /etc/mysql/my.cnf
Есть и другой путь решения этой проблемы. Если такая скорость обработки запросов считается нормальной, можно увеличить время ожидания ответа от сервера. Для этого измените значение параметра wait_timeout. Это время в секундах, на протяжении которого надо ждать ответа от сервера. Например:
После любых изменений не забудьте перезапустить MySQL сервер:
sudo systemctl restart mysql
sudo systemctl restart mariadb
2. Слишком большой пакет
Если ваш клиент MySQL создаёт слишком большие пакеты с запросами к серверу, это тоже может стать причиной такой ошибки. Максимально доступный размер пакета можно увеличить с помощью параметра max_allowed_packet. Например:
sudo vi /etc/mysql/my.cnf
Обратите внимание, что если вы из своей программы отправляете большие пакеты, то, скорее всего, вы делаете что-то не так. Не надо генерировать запросы к MySQL с помощью циклов for. SQL — это отдельный язык программирования, который многое может сделать сам, без необходимости писать очень длинные запросы.
3. Сервер неверно проинициализирован
Такая проблема может возникать при разворачивании контейнера MySQL или MariaDB в Docker. Дело в том, что на первоначальную инициализацию контейнера нужно много времени: около нескольких минут. Если вы не дадите контейнеру завершить инициализацию, а остановите его и потом снова запустите, то база данных будет всегда возвращать такую ошибку.
Вам нужно полностью удалить данные контейнера с базой данных. Например, с помощью docker-compose:
docker rm mysql-container
Здесь mysql-container — это имя контейнера с базой данных. А затем надо удалить хранилище (volume) с некорректно проинициализированной базой. Сначала посмотрите список всех хранилищ:
docker volume ls
Затем удалите нужное:
docker volume rm имя_хранилища
После этого можете снова запускать инициализацию приложения, только на этот раз дождитесь, пока сервер баз данных сообщит, что он готов, и вы сможете к нему подключиться.
Выводы
В этой небольшой статье мы рассмотрели, что значит ошибка MySQL Server has gone away, а также как её исправить на сервере или в контейнере Docker. Вы знаете ещё другие причины и решения этой проблемы? Пишите в комментариях!
Источник
Частые вопросы
Ошибки базы данных
| MySQL server has gone away или Lost connection to server during query |
| В процессе выполнения запроса сервер оборвал соединение. Проблема связана с настройкой MySQL и часто возникает когда на сервере установлен небольшой лимит времени на соединение.
Установите в bitrix/php_interface/after_connect.php: $DB->Query(«SET wait_timeout=28800»); Если проблема останется — обратитесь к администратору хостинга. Наверх |
| Не отвечает сервер при сохранении данных формы под MSSQL |
| Проблема часто возникает из за низкого значения параметра PHP odbc.defaultlrl, по умолчанию равного 4096.
Вам необходимо существенно увеличить его, например, до 64000. Наверх |
| При переносе на другой хостинг: «#1064 — You have an error in your SQL syntax. ‘DEFAULT CHARSET=. « |
| Проблема возникает в связи с тем, что дамп БД создается в MySQL версии 4.1 или выше, а устанавливается на более ранней версии MySQL, которая не поддерживает объявление кодировки для таблицы.
Для решения проблемы воспользуйтесь опцией mysqldump: —compatible=mysql40 Наверх |
| При установке на Oracle выдает следующую ошибку: ORA-01704: string literal too long |
| Скорее всего, Вы устанавливаете систему при установленной кодировке UTF8 в Oracle.
Установите значение параметра NLS_LANG, например, в AMERICAN_AMERICA.CL8MSWIN1251 Значение параметра Вы можете прописать в реесте Windows, в ветке HLM/SOFTWARE/ORACLE Наверх |
| Неправильно сортируются элементы в списках |
| Возможны разные варианта проблемы:
Обратитесь за решением данной проблемы к администратору хостинга. 2. Проверьте значения, отвечающие за кодировку БД: character_set, или, для версий MySQL 4.1 и выше, character_set_server и character_set_database. При использовании кодировки, отличной от cp1251 (кириллица), например, latin1, сортировка по строкам, содержащим символы кириллицы, будет производиться некорректно. Проверить это можно выполнив запрос к БД show variables like ‘char%’; Для решения проблемы установить в файле /bitrix/php_interface/after_connect следующие строки $DB->Query(«SET NAMES cp1251»); Если указанные действия не помогают, то выполните перенос системы (установку) еще раз, создавая дамп БД в кодировке cp1251 и создав новую БД тоже в кодировке cp1251. Наверх |
| Server shutdown in progress |
| Часто такая ошибка возникает, когда на сервере установлено ограничение на ресурсы, отводимое операционной системой на тот или иной процесс. Вам нужно обратиться к системному администратору хостинга с тем, чтобы он дал ответ — по какой причине процесс mysql-сервера перезапускается.
Наверх |
| Out of range value adjusted for column ‘USER_ID’ или Incorrect integer value: » for column ‘SESS_SESSION_ID’ |
| Скорее всего, у вас установлен MySQL версии 5.x
Вам необходимо из значения для переменной sql-mode убрать STRICT_TRANS_TABLES. 1 вариант: изменение конфигурации сервера через my.cnf. Например, sql-mode=»NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION» sql-mode=»STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION» 2 вариант: если у Вас нет доступа к конфигурационным файлам MySQL-сервера, попробуйте в /bitrix/php_interface/after_connect.php добавить строку: $DB->Query(«set sql_mode=»») Подробнее на официальном сайте: Наверх |
| Access denied for user: ‘ user @%’ to database ‘dab_test’ |
| Начиная с 4-ой версии MySQL права на LOCK назначаются отдельно.
Необходимо дополнительно назначить права на LOCK TABLES для данного пользователя базы данных. Наверх |
| DB query error. Please try later |
| Для решения проблемы в файле /bitrix/php_interface/dbconn.php установите значение переменной $DBDebug в значение true.
После этого обновите страницу: на экране появится текст ошибки. Передайте его в службу нашу поддержки. Наверх |
| Out of memory; restart server and try again (needed XXXXX bytes) |
| Эта ошибка говорит о том, что MySQL-серверу не хватает памяти на выборку данных. Достаточно часто такая проблема решается перезагрузкой веб-сервера и MySQL.
Также рекомендуем вам установить следующие значения для MySQL в файле my.cnf: key_buffer = 64M Если какие-то из рекомендуемых значений меньше установленных сейчас, оставьте эти значения прежними. Наверх |
| Got error 28 from table handler |
| Это сообщение об ошибке означает, что не осталось свободного дискового пространства для работы MySQL.
Обратитесь к системному администратору Вашего сервера для решения проблемы. Наверх |
| Ошибки БД: «Incorrect key file», «Can’t open file», «Incorrect information in file» и др. |
| Эта проблема характерна для базы данных MySQL, таблиц в формате MyISAM.
Для решения проблемы в окне SQL-запроса выполните repair table b_search_content_stem b_search_content_stem — имя неработающей таблицы. Есть возможность выполнить восстановление всех таблиц при неработающем сайте. Для этого надо знать логин и пароль к базе данных, передать их на страницу проверки. Источник MySQL Server Has Gone Away — как пофиксить
Технический редактор Highload
Ошибка MySQL Server Has Gone Away (error 2006) может возникнуть в двух случаях.
Собираем на дрон для штурмовиков Николаевской области. Он поможет найти и уничтожить врага Таймаут соединенияНаиболее распространенная проблема: таймаут соединения, в результате чего сервер его закрывает. Решение весьма тривиальное — увеличение лимита времени wait_timeout в файле конфигурации my.cnf . Для этого в Debian нужно выполнить: Открытие файла настроек MySQL Затем установить тайм-аут ожидания: Время ожидания в секундах, можно установить вплоть до 28800 с (8 часов)
Не забудьте перезагрузить базу: Перезагрузка базы данных MySQL Иногда, при выполнении длительных запланированных задач, также может появиться ошибка MySQL Server Has Gone Away все из-за того же таймаута соединения. При этом лимит времени не получится существенно увеличить (максимум до нескольких часов), так как это может привести к заполнению буфера ожидающими соединениями. Поэтому лучше проверить соединение и, при необходимости, переподключиться. Подключение БД и переподключение при необходимости Большой или некорректный пакетВторая распространенная проблема: сервер получает большой или некорректный пакет и отклоняет его. В этом случае сервер считает, что проблема на стороне клиента и закрывает соединение. Так что для решения нужно увеличить лимит на максимальный размер пакета все в том же файле конфигурации: Увеличение лимита размера входящего пакета, в МБ Также не забудьте перезагрузить базу данных. Самое главноеПосле того, как устраните ошибку MySQL Server Has Gone Away, поиграйтесь с параметрами wait_timeout и max_allowed_packet для получения оптимальных лимитов. Этот текст был написан несколько лет назад. С тех пор упомянутые здесь инструменты и софт могли получить обновления. Пожалуйста, проверяйте их актуальность. Источник Adblock |
Эта ошибка означает, что MySQL сервер запущен, но он отказывает вам в соединении. Это может произойти по нескольким причинам. Самых основных и часто встречающихся причин три: сервер перегружен, и у вас истекло время ожидания ответа, ваш клиент отправил слишком большой пакет или сервер был не до конца проинициализирован.
В этой небольшой статье мы рассмотрим более подробно, почему возникает ошибка 2006: MySQL server has gone away, а также — как её исправить.
Такую ошибку вы можете увидеть во время подключения к базе данных с помощью PHP, консольного клиента или, например, в PhpMyAdmin:
1. Истекло время ожидания
Как я уже писал выше, одной из причин может быть таймаут ожидания соединения. Возможно, сервер баз данных перегружен и не успевает обрабатывать все соединения. Вы можете подключиться к серверу с помощью консольного клиента, если вам это удастся, и попытаться выполнить какой-либо запрос, чтобы понять, действительно ли запросы выполняются слишком долго. Если это так, можно оптимизировать производительность MySQL с помощью скрипта MySQLTuner.
В большинстве случаев надо увеличить размер пула движка InnoDB с помощью параметра innodb_buffer_pool_size. Какое значение лучше поставить, можно узнать с помощью указанного выше скрипта. Например, 800 мегабайт:
sudo vi /etc/mysql/my.cnf
innodb_buffer_pool_size=800M
Есть и другой путь решения этой проблемы. Если такая скорость обработки запросов считается нормальной, можно увеличить время ожидания ответа от сервера. Для этого измените значение параметра wait_timeout. Это время в секундах, на протяжении которого надо ждать ответа от сервера. Например:
wait_timeout=600
После любых изменений не забудьте перезапустить MySQL сервер:
sudo systemctl restart mysql
или:
sudo systemctl restart mariadb
2. Слишком большой пакет
Если ваш клиент MySQL создаёт слишком большие пакеты с запросами к серверу, это тоже может стать причиной такой ошибки. Максимально доступный размер пакета можно увеличить с помощью параметра max_allowed_packet. Например:
sudo vi /etc/mysql/my.cnf
max_allowed_packet=128M
Обратите внимание, что если вы из своей программы отправляете большие пакеты, то, скорее всего, вы делаете что-то не так. Не надо генерировать запросы к MySQL с помощью циклов for. SQL — это отдельный язык программирования, который многое может сделать сам, без необходимости писать очень длинные запросы.
3. Сервер неверно проинициализирован
Такая проблема может возникать при разворачивании контейнера MySQL или MariaDB в Docker. Дело в том, что на первоначальную инициализацию контейнера нужно много времени: около нескольких минут. Если вы не дадите контейнеру завершить инициализацию, а остановите его и потом снова запустите, то база данных будет всегда возвращать такую ошибку.
Вам нужно полностью удалить данные контейнера с базой данных. Например, с помощью docker-compose:
docker-compose down
или вручную:
docker rm mysql-container
Здесь mysql-container — это имя контейнера с базой данных. А затем надо удалить хранилище (volume) с некорректно проинициализированной базой. Сначала посмотрите список всех хранилищ:
docker volume ls
Затем удалите нужное:
docker volume rm имя_хранилища
После этого можете снова запускать инициализацию приложения, только на этот раз дождитесь, пока сервер баз данных сообщит, что он готов, и вы сможете к нему подключиться.
Выводы
В этой небольшой статье мы рассмотрели, что значит ошибка MySQL Server has gone away, а также как её исправить на сервере или в контейнере Docker. Вы знаете ещё другие причины и решения этой проблемы? Пишите в комментариях!
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
Об авторе
Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.
Две наиболее распространенные причины получения ошибки MySQL server has gone away (error 2006) это..
- Сервер закрыл соединение по таймауту.
Исправить можно так: проверить чтобы значение переменной wait_timeout в конфиг файле MySql — my.cnf было достаточным для выполнения скрипта.
На Debian: нужно выполнитьsudo nano /etc/mysql/my.cnf
и установить wait_timeout = 600 ( значение задается в секундах, если ошибка не пропадет поиграйтесь с этим значением, чтобы найти оптимальное), после этого нужно рестартануть MySQL:
sudo /etc/init.d/mysql restart
Я не проверял, но значение по-умолчанию для wait_timeout можно установить вплоть до 28800 секунд (8 часов).
- Сервер сбрасывает (отклоняет) неправильные или слишком большие пакеты. Если mysqld получает пакет данных, который слишком большой или не корректный, он думает что что-то пошло не так или с клиентом случилась какая-то беда и закрывает соединение. Часто такая ошибка возникает при импорте дампов содержащих большие тексты.
Так же такое происходит, когда у Вас слишком большой запрос. Например, вы хотите в поле типа longtext записать какую-нибудь книгу, в которой текста на 20 мб. Либо хотите сохранить большой файл (например картинку) в поле с типом blob. В итоге у вас получается запрос по типу
UPDATE books SET text=«сууупер..длинный..текст» WHERE id=1
Если это Ваш случай, то подумайте действительно ли Вам нужно сохранять такой текст/файл в базу, обычная практика в таких случаях, сохранить его в файл на диск, а в базу сохранить имя этого файла. Типа того
file_put_content(‘book.txt’, ‘сууупер..длинный..текст’);
...
UPDATE books SET filename=«book.txt» WHERE id=1
Исправить можно так: вы можете увеличить максимальный размер пакета увеличив значение max_allowed_packet в файле my.cnf.
На Debian нужно выполнить:sudo nano /etc/mysql/my.cnf
и установить max_allowed_packet = 64M (если ошибка не пропадет поиграйтесь с этим значением, чтобы найти оптимальное), после этого нужно рестартануть MySQL
sudo /etc/init.d/mysql restart
Про max_allowed_packet я так же писал здесь: ERROR 2006 (HY000) — MySQL server has gone away
Если Вы получаете ошибку MySQL server has gone away (error 2006) при использовании драйвера MySQL ODBC – можете попробовать это решение.
Оригинал исходной статьи (на англ): How to fix “MySQL server has gone away” (error 2006)
Похожие статьи
Автор:
| Рейтинг: 5/5 |
Теги:
В логах ошибок PHP иногда можно встретить записи типа MySQL Server Has Gone Away (error 2006). Они означают, что соединение с сервером баз данных (ожидание сессии) прервалось по таймауту. Ошибку можно легко исправить.
Ошибка MySQL Server Has Gone Away (error 2006) может возникнуть в двух случаях:
- Соединение с MYSQL прерывается по таймауту, передача данных не успевает завершится в рамках сессии.
- Пакет, который передается слишком большой или некорректный
Быстрым решением является увеличение значений двух глобальных переменных MySQL. Делается это в основном конфигурационном файле сервера баз данных /etc/mysql/my.cnf или в консоли MySQL авторизовавшись как root
В консоли это выглядит так:
set @@GLOBAL.max_allowed_packet=96000000;
set @@GLOBAL.wait_timeout=1000;
Решение с внесением изменений в файл /etc/mysql/my.cnf.
ВАРИАНТ 1 — Таймаут соединения С БД
Программный код может делать запрос в базу данных, который обрабатывается больше максимального времени выполнения запроса, установленного в конфигурационном файле. При этом срабатывает ограничение на время ожидания в сессии.
Лучше всего выяснить почему такие запросы имеют место и оптимизировать их, но для того чтобы получить мгновенный результат нужно увеличить значение параметра wait_timeout. Значение задается в секундах и не может быть более 28800.
mcedit /etc/mysql/my.cnf
wait_timeout = 1000
После внесения любых изменений в конфигурационный файл перезапускаем MySQL
/etc/init.d/mysql restart
ВАРИАНТ 2 — СЛИШКОМ Большой пакет
Несколько другая ситуация имеет место когда сервер отклоняет пакет из-за его слишком большого размера (или в случае если сервер не может распознать пакет по той или иной причине). В логи при этом пишутся точно такие же сообщения.
Решение в этом случае практически такое же — необходимо скорректировать значение одной переменной в конфигурационном файле.
mcedit /etc/mysql/my.cnf
[mysqld]
max_allowed_packet = 96M
В примере задан максимальный размер пакета, который сервер не будет отвергать — 96 Мб. Устанавливать слишком большие значения не стоит.
Также перезапускаем MySQL
/etc/init.d/mysql restart
Таким образом, РНР ошибка mysql server has gone away в большинстве случаев побеждается корректировкой значений двух переменных и перезапуском сервера баз данных.
Ошибка 2006 под названием MySQL Sever has gone away означает отказ сервера в соединении даже при условии, что он запущен. Известно всего три причины, почему ошибка появляется. Первая причина – сервер перегружен. Время ожидания истекло. Вторая причина – клиент отправил слишком больной пакет. Третья – сервер не был до конца проинициализирован. Дальше подробно рассмотрим, по каким причинам появляется ошибка и как с ней бороться.
Как исправить ошибку
Обычно ошибка появляется при попытке подключиться к базе данных при помощи PHP, консольного клиента, а также в случае использования PhpMyAdmin:
Давайте дальше рассмотрим каждую ситуацию в отдельности.
Истекло время ожидания
Как было сказано в начале статьи, одна из возможных причин – истечение времени ожидания. Может быть так, что сервер был перегружен и не справляется с нагрузкой – обработкой всех соединений. Чтобы понять, насколько долго выполняются серверные запросы, можно воспользоваться любым консольным клиентом и подключиться к серверу. Если вам удастся это сделать, выполните любой запрос. Если на обработку запросов уходит слишком много времени, оптимизировать MySQL можно при помощи специального скрипта MySQLTuner. Обычно увеличивается размер пула движка InnoDB путем установки параметра innodb_buffer_pool_size. Оптимальное значение определяется при помои приведенного выше скрипта.
Если это 800 мегабайт (может быть и другой размер), прописываем:
$ sudo vi /etc/mysql/my.cnf
innodb_buffer_pool_size=800M
Существует и другой способ решения проблемы. Для этого увеличивают время ответа от сервера. Чтобы выполнить эту задачу, необходимо изменить параметр wait_timeout. Это время в секундах, на протяжении которого надо ждать ответа от сервера.
Например:
wait_timeout=500
Внося изменения, не забываем дальше перезагрузить сервер:
$ sudo systemctl restart mysql
или:
$ sudo systemctl restart mariadb
Слишком большой пакет
Когда клиент пользователя создает слишком большое количество пакетов, сервер выдаст именно эту ошибку. Доступный размер пакета (максимальное значение) можно увеличить с помощью параметра max_allowed_packet.
Например:
$ sudo vi /etc/mysql/my.cnf
max_allowed_packet=128M
Отдельно обратите внимание на клиент, ведь если он посылает много запросов, то вы явно что-то делает не так. Как минимум не стоит генерировать запросы к MySQL с помощью циклов for.
Сервер неверно проинициализирован
Если вы решите развернуть MySQL или MariaDB в Docker, то будьте готовы столкнуться с подобной ошибкой. Первоначальная инициализация контейнера требует чуть больше свободного времени. Если не дать контейнеру завершить инициализацию, сперва остановив его и запустив, то база данных будет всегда возвращать такую ошибку. Решение – нужно полностью удалить данные контейнера с базой данных.
Делается это так:
$ docker-compose down
или:
$ docker rm mysql-container
Дальше надо удалить хранилище (volume) с некорректно проинициализированной базой. Но в начале просмотрите список всех хранилищ:
$ docker volume ls
После удаляем:
$ docker volume rm имя_хранилища
Теперь можете запустить инициализацию приложения, только дождитесь, пока сервер баз данных сообщит, что он готов, и вы сможете к нему подключиться.