ERROR 2006 (HY000): сервер MySQL ушел

Ответ 1

max_allowed_packet=64M

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

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

В Windows этот файл находится по адресу: "C:\ProgramData\MySQL\MySQL Server 5,6"

В Linux (Ubuntu):/etc/mysql

Ответ 2

Вы можете увеличить Max Allowed Packet

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

Ответ 3

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

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

Ответ 4

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

Ошибка: 2006 (CR_SERVER_GONE_ERROR) - сервер MySQL исчез

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

mysql импорт

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

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

• Добавьте опцию force (-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" # or:
    mysql -sve "SHOW VARIABLES LIKE '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 ошибки 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;
}

Ответ 5

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

$> mysqladmin variables -u user -p 

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

mysql> SET GLOBAL max_allowed_packet=1072731894

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

Ответ 6

Я решил ошибку 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)

Ответ 7

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

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

max_allowed_packet=500M

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

Ответ 8

Вы также можете войти в базу данных с правами 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';

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

Как я уже сказал, я добавляю свой собственный ответ. Рад видеть, что это работает!

Ответ 9

Решение заключается в увеличении значений, заданных параметрами 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

Ответ 10

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

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

$mysql db_name < source.sql

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

Ответ 11

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

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

Источник: Для homebrew mysql installs, где my.cnf?

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

3. mysql.server restart

Ответ 12

Для получения дополнительной информации об этом см. http://dev.mysql.com/doc/refman/5.5/en/gone-away.html или http://dev.mysql.com/doc/refman/5.1/en/gone-away.html при необходимости.

Ответ 13

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

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

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

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

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

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

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

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

Ответ 18

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

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

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

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

Ответ 19

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

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