ОШИБКА 2006 (HY000): сервер MySQL исчез

Вы можете увеличить 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

Глобальное обновление и настройки 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 import

В вашем конкретном случае при импорте файла базы данных через 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" # 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.

Исходный код

Исходный код, ответственный за выброс ошибки CR_SERVER_GONE_ERROR (mysqlx.cc):

void Connection::throw_mysqlx_error(const boost::system::error_code &error)
{
  if (!error)
    return;

  switch (error.value())
  {
    // OSX return this undocumented error in case of kernel race-conndition
    // lets ignore it and next call to any io function should return correct
    // error
    case boost::system::errc::wrong_protocol_type:
    return;
    case boost::asio::error::eof:
    case boost::asio::error::connection_reset:
    case boost::asio::error::connection_aborted:
      throw Error(CR_SERVER_GONE_ERROR, "MySQL server has gone away");

    case boost::asio::error::broken_pipe:
      throw Error(CR_BROKEN_PIPE, "MySQL server has gone away");

    default:
      throw Error(CR_UNKNOWN_ERROR, error.message());
  }
}

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

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

max_allowed_packet=500M

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

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

$> 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

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

• Создан /etc/my.cnf, как рекомендовали другие, со следующим содержимым: [mysql] connect_timeout = 43200 max_allowed_packet = 2048M net_buffer_length = 512M debug-info = TRUE
• Добавление флагов --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 Рассылка 5.5.51 для osx10.8 (i386)

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

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

$mysql db_name < source.sql

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

Если вы находитесь на 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

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

Я столкнулся с этой ошибкой, когда я использую 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), но информация о таблице не отображается.

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

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

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, и она удалит и заново создаст нужные вам таблицы.

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

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

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

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

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

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