Подключение к базе данных не удалось неизвестная ошибка код ошибки 2006

Доброго времени суток. Подскажите пожалуйста что это за ошибка — #2006 Невозможно подключиться к серверу MySQL. Выходит она при входе через phpmyadmin, после того как ввиду логин и пароль. Сервер установлен локально. Ошибку эту начало выдавать после того как я импортировал в WP xml файл который прилагался к шаблону ( демо контент ). В этих делах просто я новичок-любитель, просто появился интерес как это исправить. Заранее благодарен!!!

Эта ошибка означает, что 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 при копировании материала ссылка на источник обязательна .

Об авторе

Автор:
| Рейтинг: 5/5 |
Теги:

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

$ ls -s file.sql 
79512 file.sql

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

Ответы:

max_allowed_packet=64M

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg)); if (net_write_command(net,(uchar) command, header, header_length, arg, arg_length)) { set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate); goto end; }

$> mysqladmin variables -u user -p 

mysql> SET GLOBAL max_allowed_packet=1072731894

max_allowed_packet=500M

set global max_allowed_packet=64*1024*1024;

[mysqld] max_allowed_packet=64M

show variables like 'max_allowed_packet';

[mysqld] port=3306 explicit_defaults_for_timestamp = TRUE connect_timeout = 1000000 net_write_timeout = 1000000 wait_timeout = 1000000 max_allowed_packet = 1024M interactive_timeout = 1000000 net_buffer_length = 200M net_read_timeout = 1000000 set GLOBAL delayed_insert_timeout=100000

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

CREATE TABLE `mytab` ( .. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

when creating the backup, first backup structure and be sure of add: DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT CREATE PROCEDURE / FUNCTION / EVENT IF NOT EXISTS AUTO_INCREMENT

mysql -h <hostname> -u username -p <databasename> < file.sql

Я получаю эту ошибку, когда пытаюсь получить большой файл SQL (большой запрос INSERT).

mysql> source file.sql ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 2 Current database: *** NONE *** ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 3 Current database: *** NONE *** 

В таблице ничего не обновляется. Я пробовал удалить и восстановить таблицу / базу данных, а также перезапустить MySQL. Ничто из этого не решает проблему.

Вот мой максимальный размер пакета:

+--------------------+---------+ | Variable_name | Value | +--------------------+---------+ | max_allowed_packet | 1048576 | +--------------------+---------+ 

Вот размер файла:

$ ls -s file.sql 79512 file.sql 

Когда я пробую другой метод …

$ ./mysql -u root -p my_db < file.sql Enter password: ERROR 2006 (HY000) at line 1: MySQL server has gone away 

max_allowed_packet=64M

Добавление этой строки в файл my.cnf решает мою проблему.

Это полезно, когда столбцы имеют большие значения, которые вызывают проблемы, вы можете найти объяснение здесь.

В Windows этот файл находится по адресу: «C: ProgramData MySQL MySQL Server 5.6».

В Linux (Ubuntu): / etc / mysql

Глобальное обновление и настройки my.cnf у меня почему-то не работали. Здесь работала передача значения max_allowed_packet напрямую клиенту:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

В общем ошибка:

Ошибка: 2006 (CR_SERVER_GONE_ERROR) — сервер MySQL отключен

Означает, что клиент не смог отправить вопрос серверу .

mysql импорт

В вашем конкретном случае при импорте файла базы данных через mysql это, скорее всего, означает, что некоторые запросы в файле SQL слишком велики для импорта и не могут быть выполнены на сервере, поэтому клиент не работает на первая произошла ошибка.

Итак, у вас есть следующие возможности:

• Добавьте параметр силы (-f) для mysql, чтобы продолжить и выполнить остальные запросы.

  Это полезно, если в базе данных есть несколько больших запросов, связанных с кешем, которые в любом случае не актуальны.

• Увеличьте max_allowed_packet и wait_timeout в конфигурации вашего сервера (например, ~/.my.cnf).

• Выгрузите базу данных, используя опцию --skip-extended-insert, чтобы разбить большие запросы. Затем снова импортируйте его.

• Попробуйте применить параметр --max-allowed-packet для mysql.

Общие причины

Обычно эта ошибка может означать несколько вещей, например:

• запрос к серверу неверный или слишком большой,

  Решение: Увеличьте max_allowed_packet переменную .

  • Убедитесь, что переменная находится в разделе [mysqld], а не [mysql].

  • Не бойтесь использовать большие числа для тестирования (например, 1G).

  • Не забудьте перезапустить сервер MySQL / MariaDB.

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

      mysql -sve "SELECT @@ max_allowed_packet" # или: mysql -sve "ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'max_allowed_packet'" 

• Вы получили тайм-аут от соединения TCP / IP на стороне клиента.

  Решение: Увеличьте переменную wait_timeout .

• Вы пытались выполнить запрос после того, как соединение с сервером было закрыто.

  Решение: необходимо исправить логическую ошибку в приложении.

• Ошибка поиска имени хоста (например, проблема с DNS-сервером), или сервер был запущен с опцией --skip-networking.

  Другая возможность заключается в том, что ваш брандмауэр блокирует порт MySQL (например, 3306 по умолчанию).

• Выполняющийся поток был прерван, поэтому повторите попытку.

• Вы столкнулись с ошибкой, из-за которой сервер умер при выполнении запроса.

• Клиент, работающий на другом хосте, не имеет необходимых прав для подключения.

• И многое другое, так что узнайте больше по адресу: B.5.2.9 MySQL сервер ушел.

Отладка

Вот несколько идей отладки на уровне экспертов:

• Проверьте журналы, например

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error") 

• Проверьте свое соединение с помощью mysql, telnet или функций ping (например, mysql_ping в PHP).

• Используйте tcpdump для прослушивания сообщений MySQL (не будет работать для подключения через сокет), например:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings 

• В Linux используйте strace. В BSD / Mac используйте dtrace / dtruss, например

  sudo dtruss -a -fn mysqld 2>&1 

  См .: Начало работы с DTracing MySQL

Узнайте больше о том, как отлаживать сервер или клиент MySQL, по адресу: 26.5 Отладка и перенос MySQL < / а>.

Для справки проверьте исходный код в sql-common/client.c, ответственный за выдачу ошибки CR_SERVER_GONE_ERROR для клиентской команды.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
arg, arg_length))
{
set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
goto end;
}

Я решил ошибку ERROR 2006 (HY000) at line 97: MySQL server has gone away и успешно перенес файл sql размером> 5 ГБ, выполнив следующие два шага по порядку:

1. Создан /etc/my.cnf, как рекомендовали другие, со следующим содержимым:

   [mysql] connect_timeout = 43200 max_allowed_packet = 2048M net_buffer_length = 512M debug-info = TRUE 

2. Добавление флагов --force --wait --reconnect к команде (т. Е. mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Важное примечание: необходимо было выполнить оба шага, потому что, если я не удосужился внести изменения в файл /etc/my.cnf, а также добавить эти флаги, некоторые таблицы отсутствовали после импорта.

Используемая система: OSX El Capitan 10.11.5; mysql Ver 14.14 Distrib 5.5.51 для osx10.8 (i386)

На всякий случай для проверки переменных можно использовать

$> mysqladmin variables -u user -p 

Это отобразит текущие переменные, в данном случае max_allowed_packet, и, как кто-то сказал в другом ответе, вы можете временно установить его с помощью

mysql> SET GLOBAL max_allowed_packet=1072731894

В моем случае файл cnf не был учтен, и я не знаю почему, поэтому код SET GLOBAL действительно помог.

Вы также можете войти в базу данных как root (или с привилегиями SUPER) и сделать

set global max_allowed_packet=64*1024*1024;

Также не требует перезапуска MySQL. Обратите внимание, что вам следует исправить файл my.cnf, как указано в других решениях:

[mysqld]
max_allowed_packet=64M

И подтвердите изменение после перезапуска MySQL:

show variables like 'max_allowed_packet';

Вы также можете использовать командную строку, но для этого может потребоваться обновление сценариев запуска / остановки, которые могут не выдержать системных обновлений и исправлений.

В соответствии с просьбой, я добавляю сюда свой собственный ответ. Рад видеть, что он работает!

Решение заключается в увеличении значений параметров wait_timeout и connect_timeout в вашем файле параметров под тегом [mysqld].

Мне пришлось восстановить резервную копию mysql размером 400 МБ, и это сработало для меня (значения, которые я использовал ниже, немного преувеличены, но вы поняли):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

Blockquote

У меня была та же проблема, но изменение max_allowed_packet в файле my.ini / my.cnf в [mysqld] помогло.

Добавить строку

max_allowed_packet=500M

Теперь перезапустите службу MySQL, как только вы закончите.

Здесь может происходить пара вещей;

• Ваш INSERT работает долго, и клиент отключается. Когда он повторно подключается, он не выбирает базу данных, отсюда и ошибка. Один из вариантов здесь — запустить командный файл из командной строки и выбрать базу данных в аргументах, например:

$ mysql db_name

• Другой — запустить вашу команду через php или на другом языке. После каждого продолжительного оператора вы можете закрыть и снова открыть соединение, убедившись, что вы подключены в начале каждого запроса.

Если вы используете Mac и установили mysql через brew, как я, сработало следующее.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Источник: Где my.cnf для установки homebrew?

1. добавить max_allowed_packet=1073741824 в /usr/local/etc/my.cnf

2. mysql.server restart

Я столкнулся с этой ошибкой, когда использую Mysql Cluster, я не знаю, что этот вопрос связан с использованием кластера или нет. Поскольку ошибка точно такая же, дайте мне решение здесь. Получение этой ошибки из-за внезапного сбоя узлов данных. Но когда узлы выходят из строя, вы все равно можете получить правильный результат с помощью cmd:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Да и mysqld тоже работает правильно. Так что сначала я не могу понять, что не так. И примерно через 5 минут результат ndb_mgm показывает, что узел данных не работает. Тогда я понимаю, в чем проблема. Итак, попробуйте перезапустить все узлы данных, тогда сервер mysql вернулся, и все в порядке.

Но одна вещь для меня странная: после того, как я потерял сервер mysql для некоторых запросов, когда я использую cmd, например show tables, я все еще могу получить информацию о возврате, например 33 rows in set (5.57 sec), но информация о таблице не отображается.

Это сообщение об ошибке также появляется, когда вы создали СХЕМУ с другим СОБРАНИЕМ, отличным от того, который используется в дампе. Итак, если дамп содержит

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Вы также должны отразить это в сопоставлении SCHEMA:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Я использовал utf8mb4_general_ci в схеме, потому что мой скрипт был получен из новой установки V8, теперь загрузка БД на старой версии 5.7 вылетела, и я почти с ума сошел.

Так что, может быть, это поможет вам сэкономить утомительные часы …

(MacOS 10.3, mysql 5.7)

Если он повторно подключается и получает идентификатор соединения 2, сервер почти наверняка просто упал.

Свяжитесь с администратором сервера и попросите его диагностировать проблему. Никакой незлонамеренный SQL не должен приводить к сбою сервера, и вывод mysqldump определенно не должен.

Вероятно, администратор сервера допустил большую операционную ошибку, такую ​​как присвоение размеров буфера больше, чем ограничения адресного пространства архитектуры, или больше, чем емкость виртуальной памяти. Журнал ошибок MySQL, вероятно, будет содержать некоторую важную информацию; они будут следить за этим, если они в любом случае компетентны.

Для amazon RDS (это мой случай) вы можете изменить значение параметра max_allowed_packet на любое числовое значение в байтах, которое имеет смысл для самых больших данных в любой вставке, которая у вас может быть (например, если у вас есть значения blob размером 50 МБ в свою вставку, установите max_allowed_packet на 64M = 67108864) в новом или существующем parameter-group. Затем примените эту группу параметров к своему экземпляру MySQL (может потребоваться перезагрузка экземпляра).

Для пользователей Drupal 8, которые ищут решение проблемы с импортом БД:

В конце файла дампа sql могут быть команды, вставляющие данные в таблицу «webprofiler». Это, я думаю, какой-то файл журнала отладки, и это не очень важно для работы сайта, поэтому все это можно удалить. Я удалил все эти вставки, включая LOCK TABLES и UNLOCK TABLES (и все, что между ними). Он находится в самом низу файла sql. Проблема описана здесь:

https://www.drupal.org/project/devel/issues/2723437

Но для этого нет решения, кроме усечения этой таблицы.

Кстати, я пробовал все решения из ответов выше, и больше ничего не помогло.

Я пробовал все вышеперечисленные решения, все не удалось.

В итоге я использовал -h 127.0.0.1 вместо стандартного var/run/mysqld/mysqld.sock.

Если вы пробовали все эти решения, особенно. увеличивая max_allowed_packet до максимального поддерживаемого количества 1GB, и вы все еще видите эти ошибки, возможно, вашему серверу буквально не хватает свободной оперативной памяти …

Решение = обновите ваш сервер до большего объема оперативной памяти и попробуйте еще раз.

Примечание: я удивлен, что это простое решение не было упомянуто после более чем 8-летнего обсуждения в этой ветке … иногда мы, разработчики, склонны слишком много обдумывать.

Если ни один из этих ответов не решает проблему, я решил ее, удалив таблицы и автоматически создав их следующим образом:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

Затем просто используйте эту резервную копию с вашим БД, и она удалит и воссоздает нужные вам таблицы.

Затем вы делаете резервную копию только данных и делаете то же самое, и все будет работать.

Как насчет использования клиента mysql следующим образом:

mysql -h <hostname> -u username -p <databasename> < file.sql

У меня была такая же проблема с XAMMP

Метод-01: я изменил max_allowed_packet в файле D:xamppmysqlbinmy.ini следующим образом:

max_allowed_packet = 500 МБ

Наконец, перезапустите службу MySQL один раз и все готово.

Метод-02:

Более простой способ, если вы используете XAMPP. Откройте панель управления XAMPP и нажмите кнопку конфигурации в разделе mysql.

Теперь щелкните my.ini, и он откроется в редакторе. Обновите max_allowed_packet до необходимого размера.

Затем перезапустите службу mysql. Нажмите «Остановить» в сервисе Mysql, нажмите «Пуск» снова. Подождите несколько минут.

Затем попробуйте снова запустить запрос Mysql. Надеюсь, это сработает.

Это более редкая проблема, но я видел это, если кто-то скопировал весь каталог / var / lib / mysql как способ переноса своей БД на другой сервер. Причина, по которой это не работает, заключается в том, что база данных работала и использовала файлы журнала. Иногда это не работает, если есть логи в / var / log / mysql. Решение состоит в том, чтобы скопировать также файлы / var / log / mysql.

Добавить max_allowed_packet=64M в [mysqld]

[mysqld] 
max_allowed_packet=64M

Перезагрузите сервер MySQL.

Окончательным решением для меня было устранение ошибок, вызывающих предупреждения. Я также изменил max_allowed_packet, который помогал с меньшими файлами с ошибками. Устранение ошибок также невероятно ускорило процесс.