Попытка импортировать базу данных: сервер MySQL ушел [дубликат]

Я делаю несколько больших вычислений, которые связаны с подключением mysql, чтобы оставаться долгое время и с тяжелыми данными. я столкнулся с этой проблемой «Mysql go away». Поэтому я попытался оптимизировать запросы, но это не помогло мне, но я увеличил предел переменных mysql, который по умолчанию установлен на меньшее значение.

wait_timeout max_allowed_packet

До предела, что вам подходит, оно должно быть любым числом * 1024 (байты). вы можете войти в терминал с помощью команды mysql -u username-p и проверить и изменить эти ограничения.

У меня была эта ошибка и другие связанные, когда я импортировал файл с 16 ГБ SQL. Для меня, редактируя my.ini и устанавливая следующее (на основе нескольких разных сообщений) в разделе [mysqld]:

max_allowed_packet      = 110M
innodb_buffer_pool_size=511M
innodb_log_file_size=500M
innodb_log_buffer_size = 800M
net_read_timeout        = 600
net_write_timeout       = 600

Если вы работаете под Windows, перейдите в панель управления, службы, и посмотрите подробности для MySQL, и вы увидите, где находится my.ini. Затем, после редактирования и сохранения my.ini, перезапустите службу mysql (или перезагрузите компьютер).

Если вы используете HeidiSQL, вы также можете установить некоторые или все из них, используя это.

Я обновил «max_allowed_packet» до 1024M, но он все еще не работал. Оказывается, мой скрипт развертывания запущен:

mysql --max_allowed_packet=512M --database=mydb -u root < .\db\db.sql

Обязательно явно укажите большее число из командной строки, если вы это сделаете.

Если ваши данные включают в себя данные BLOB:

Обратите внимание, что импорт данных из командной строки, кажется, захлестнул данные BLOB, в результате чего ошибка «сервер MySQL ушла».

Чтобы избежать этого, заново создайте mysqldump, но с флагом --hex-blob:

http://dev.mysql.com/doc/refman/5.7/en/ mysqldump.html # option_mysqldump_hex-blob

, который выведет файл данных с шестнадцатеричными значениями, а не двоичными среди другого текста.

PhpMyAdmin также имеет опцию «Dump binary столбцы в шестнадцатеричной нотации (например, «abc» становится 0x616263) », который работает хорошо.

Обратите внимание, что существует давняя ошибка (по состоянию на декабрь 2015 года), что означает, что столбцы GEOM не являются convert: Резервное копирование таблицы с помощью столбца GEOMETRY с использованием mysqldump? , поэтому использование программы, такой как PhpMyAdmin, является единственным обходным решением (опция, отмеченная выше, правильно конвертирует столбцы GEOM).

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

Первым шагом, который я рекомендую, является увеличение max_allowed_packet до 128M.

Затем загрузите скрипт MySQL Tuning Primer и запустите его.

Также изучите настройку значений тайм-аута как в MySQL, так и в PHP.

Насколько велика (размер файла) это файл вы импортируете и можете ли вы импортировать файл с помощью клиента командной строки mysql вместо PHPMyAdmin?

Я решил проблему с этим коротким файлом /etc/mysql/my.cnf:

[mysqld]
wait_timeout = 600
max_allowed_packet = 100M

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

Если он сработает сразу, увеличьте переменную max_allowed_packet; он все равно не работает, убедитесь, что команда действительна SQL. У меня были неэкономленные кавычки, которые все испортили.

Кроме того, если это возможно, рассмотрите возможность ограничения числа вставок одной команды SQL, например, 1000. Вы можете создать скрипт, который создает несколько операторов из один заново, введя INSERT ... часть каждые n вставок.

Для общего хостинга GoDaddy

На учетных платах хостинга GoDaddy сложно настроить файлы PHP.ini и т. д. Однако есть и другой способ, и это просто отлично сработало для меня. (Я просто успешно загрузил текстовый файл 3.8Mb .sql, содержащий 3100 строк и 145 столбцов. Используя команду IMPORT в phpMyAdmin, я получал ужасный сервер MySQL, ушедший с ошибкой , и никакой дополнительной информации .)

Я обнаружил, что Мэтт Мэтчер имел правильный ответ. Как и Мэтт, я пробовал всевозможные трюки: экспортировать базы данных MySQL в куски размером с укусом, писать сценарии, которые ломают большой импорт на более мелкие. Но вот что сработало:

(1) CPANEL ---> FILES (group) ---> BACKUP

(2a) Под заголовком «Частичное резервное копирование» ... ( 2b) В разделе «Загрузка резервной копии базы данных MySQL» (2c) Выберите свою базу данных и загрузите резервную копию (этот шаг необязательный, но мудрый)

(3a) Непосредственно справа от 2b под заголовком «Восстановить Резервное копирование базы данных MySQL "(3b) Выберите файл импорта .SQL с вашего локального диска (3c). Истинное счастье будет вашим (коротко ....) Мое заняло около 5 секунд

Я смог использовать этот метод для импорта одной таблицы. Ничего другого в моей базе данных не было затронуто - но это то, что вышеприведенный шаг (2) предназначен для защиты от.

Примечания: a. Если вы не знаете, как создать файл импорта .SQL, используйте phpMyAdmin для экспорта таблицы и изменения этой файловой структуры.

ИСТОЧНИК: Matt Butcher 2010 Article

Если увеличение max_allowed_packet не помогает.

Я получал ту же ошибку, что и при импортировании файла .sql в мою базу данных через Sequel Pro.

Ошибка по-прежнему сохранялась после увеличения max_allowed_packet до 512M, поэтому я запускал импорт в командной строке вместо:

mysql --verbose -u root -p DatabaseName < MySQL.sql

Он дал следующую ошибку:

ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled

Я нашел пару полезных вопросов StackOverflow:

• Включить двоичный режим при восстановлении базы данных из SQL-дампа
• Mysql ERROR: ASCII '\ 0' при импорте файла sql на сервере linux

В моем случае файл .sql был немного поврежден или что-то , Дамп MySQL, который мы получаем, поставляется в двух zip-файлах, которые необходимо объединить вместе, а затем распаковать. Я думаю, что распаковка была прервана изначально, оставив файл с нечетными символами и кодировками. Получение нового дампа MySQL и его распаковка работали для меня.

Просто хотелось добавить это здесь, если другие обнаружат, что увеличение переменной max_allowed_packet не помогло.

У меня была схожая ошибка сегодня, когда дублирование базы данных (сервер MySQL ушел ...), но когда я попытался перезапустить перезапуск mysql.server, я получил ошибку

ERROR! The server quit without updating PID ...

Вот как я решил он: я открыл Приложения / Утилиты / и запустил Activity Monitor

 quit mysqld

, после чего смог решить проблему с ошибкой с помощью

mysql.server restart

Если вы работаете над XAMPP, вы можете исправить ошибку в MySQL Server с последующими изменениями.

открыть файл my.ini. Место my.ini (D: \ xampp \ mysql \ bin \ my.ini)

изменить следующие значения переменных

max_allowed_packet = 64M
innodb_lock_wait_timeout = 500

У меня такая же ошибка. Чтобы решить эту проблему, просто откройте файл my.ini .. в строке нет 36 измените значение максимально допустимого размера пакета, т.е. max_allowed_packet = 20M

Другая причина, по которой это может произойти, - нехватка памяти. Проверьте / var / log / messages и убедитесь, что ваш my.cnf не настроен, чтобы заставить mysqld выделять больше памяти, чем ваша машина.

Ваш mysqld-процесс может быть фактически убит ядром, а затем перезагрузите процесс «safe_mysqld», не понимая его.

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

сделать резервную копию моего .cnf перед изменением.

Если вы используете MAMP для OS X, вам нужно будет изменить значение max_allowed_packet в шаблоне для MySQL.

1. Вы можете найти его по адресу: Файл> Изменить template> MySQL my.cnf
2. Затем просто найдите max_allowed_packet, измените значение и сохраните.

Надеюсь, это кому-то поможет.

Для меня это решение не сработало, поэтому я выполнил

SET GLOBAL max_allowed_packet=1073741824;

в моем SQL-клиенте.

Если вы не можете изменить это с помощью службы MYSql, вам следует остановите службу и измените переменную в файле «my.ini».

Например:

max_allowed_packet=20M

Убедитесь, что процесс mysqld не перезапускается из-за таких менеджеров служб, как systemd.

У меня была эта проблема в бродяжничестве с centos 7. Усовершенствования настройки не помогли. Оказалось, что система была убита службой mysqld каждый раз, когда потребовалось слишком много памяти.