Сервер MySQL исчез при импорте большого файла sql

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

SET GLOBAL max_allowed_packet=1073741824;

В моем клиенте SQL.

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

Например:

max_allowed_packet=20M

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

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

Затем загрузите скрипт MySQL Tuning Primer и запустите его. Он предоставит рекомендации по нескольким аспектам вашей конфигурации для повышения производительности.

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

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

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

Откройте свой файл my.ini расположение my.ini (D:\xampp\mysql\bin\my.ini)

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

max_allowed_packet = 64M
innodb_lock_wait_timeout = 500

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

1. Вы можете найти его по адресу: Файл > Редактировать шаблон> MySQL my.cnf

2. Затем просто найдите max_allowed_packet, измените значение и сохраните.

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

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

[mysqld]
wait_timeout = 600
max_allowed_packet = 100M

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

Ваш процесс mysqld на самом деле может быть убит ядром, а затем перезапущен процессом "safe_mysqld" без вашего ведома.

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

Сделайте резервную копию файла my.cnf перед изменением это.

У меня была эта ошибка и другие связанные с ней, когда я импортировал файл SQL объемом 16 ГБ. Для меня, отредактировав мой файл.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, вы также можете установить некоторые или все из них используют это.

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

Обратите внимание, что импорт данных из командной строки, похоже, захлебывается данными больших двоичных объектов, что приводит к ошибке "Сервер MySQL исчез".

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

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

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

В phpMyAdmin также есть опция "Вывод двоичных столбцов в шестнадцатеричной системе счисления (например, "abc" становится 0x616263)", которая отлично работает.

Обратите внимание, что существует давняя ошибка (по состоянию на декабрь 2015 года), которая означает, что столбцы GEOM не преобразуются: Создать резервную копию таблицы со столбцом ГЕОМЕТРИИ с помощью mysqldump? таким образом, использование такой программы, как phpMyAdmin, кажется единственным обходным путем (опция, отмеченная выше, правильно преобразует геометрические столбцы).

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

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

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

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

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

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

Я получил аналогичную ошибку.. чтобы решить эту проблему, просто откройте мой файл.ini.. здесь в строке №36 измените значение максимально допустимого размера пакета, т.е. max_allowed_packet = 20 м

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

ERROR! The server quit without updating PID ...

Вот как я решил эту проблему: Я открыл Приложения/Утилиты/ и запустил Монитор активности

 quit mysqld

Затем удалось решить проблему с ошибкой с помощью

mysql.server restart

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

Wait_timeout max_allowed_пакет

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

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

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

Если увеличение 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

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

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

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

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

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

В учетных записях общего хостинга GoDaddy сложно настроить файлы PHP.ini и т. Д. Однако есть и другой способ, и он просто отлично сработал для меня. (Я только что успешно загрузил текстовый файл 3,8 Мб.sql, содержащий 3100 строк и 145 столбцов. Используя команду ИМПОРТА в phpMyAdmin, я получал страшную ошибку Сервер MySQL исчез, и никакой дополнительной информации.)

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

(1) ПАНЕЛЬ УПРАВЛЕНИЯ ---> ФАЙЛЫ (группа)---> РЕЗЕРВНОЕ КОПИРОВАНИЕ

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

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

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

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

ИСТОЧНИК: Статья Мэтта Мясника 2010 года