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

Я получаю эту ошибку при попытке получить большой файл 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

Вы можете увеличить максимально допустимый пакет

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 Импортировать

В вашем конкретном случае при импорте файла базы данных через 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или функцию звона (например , 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;
}

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

$> mysqladmin variables -u user -p 

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

mysql> SET GLOBAL max_allowed_packet=1072731894

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

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

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)

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

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

max_allowed_packet=500M

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

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

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

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

$ mysql db_name <source.sql

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

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

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

Источник: Для доморощенных установок mysql, где my.cnf?

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

3. 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), но никакая информация таблицы не отображается.

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

При повторном подключении и получении идентификатора подключения 2 сервер почти наверняка просто вышел из строя.

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

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

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

Это сообщение об ошибке также появляется, когда вы создали SCHEMA с COLLATION, отличным от того, который используется в дампе. Итак, если дамп содержит

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)

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

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