Одним из тихих убийц MySQL Connections является MySQL Packet. Даже поток ввода-вывода MySQL Replication может стать жертвой этого.
Согласно документации MySQL
Вы также можете получить эти ошибки, если отправите запрос на сервер, который является неправильным или слишком большим. Если mysqld получает слишком большой или вышедший из строя пакет, он предполагает, что с клиентом что-то не так, и закрывает соединение. Если вам нужны большие запросы (например, если вы работаете с большими BLOB-столбцами), вы можете увеличить лимит запросов, установив переменную max_allowed_packet сервера, значение которой по умолчанию равно 1 МБ. Вам также может потребоваться увеличить максимальный размер пакета на стороне клиента. Более подробная информация о настройке размера пакета приведена в разделе C.5.2.10, «Слишком большой пакет».
Операторы INSERT или REPLACE, которые вставляют большое количество строк, также могут вызывать подобные ошибки. Любой из этих операторов отправляет серверу один запрос независимо от количества вставляемых строк; таким образом, вы часто можете избежать ошибки, уменьшив количество строк, отправляемых за INSERT или REPLACE.
По крайней мере, вы должны убедиться, что размеры пакетов для компьютера, с которого вы выполняли mysqldump, и компьютера, который вы загружаете, идентичны.
Вы можете выбрать два (2) подхода:
ПОДХОД # 1: Выполните mysqldump, используя --skip-extended-insert
Это позволит убедиться, что пакет MySQL не заполнен несколькими BLOB-объектами, полями TEXT. Таким образом, SQL INSERT выполняются по одному. Основными недостатками являются
- mysqldump намного больше
- перезагрузка такой свалки занимает гораздо больше времени.
ПОДХОД № 2: Увеличить max_allowed_packet
Это может быть предпочтительным подходом, потому что реализация этого - просто перезапуск MySQL. Понимание того, что пакет MySQL, может прояснить это.
В соответствии со страницей 99 «Понимание внутренних компонентов MySQL» (ISBN 0-596-00957-7) ниже приводятся параграфы 1-3:
Код сетевого взаимодействия MySQL был написан в предположении, что запросы всегда достаточно короткие, и поэтому могут отправляться и обрабатываться сервером в одном фрагменте, который в терминологии MySQL называется пакетом . Сервер выделяет память для временного буфера для хранения пакета, и он запрашивает достаточно для его полного заполнения. Эта архитектура требует мер предосторожности, чтобы избежать исчерпания памяти на сервере - ограничение размера пакета, которое выполняет эта опция.
Интересующий код в отношении этой опции находится в
sql / net_serv.cc . Посмотрите на my_net_read () , затем выполните вызов my_real_read () и обратите особое внимание на
net_realloc () .
Эта переменная также ограничивает длину результата многих строковых функций. Смотрите sql / field.cc и
sql / intem_strfunc.cc для подробностей.
Учитывая это объяснение, массовые INSERT-ы довольно быстро загрузят / разгрузят MySQL Packet. Это особенно верно, когда max_allowed_packet слишком мал для данной загрузки данных, поступающих на него.
ВЫВОД
В большинстве установок MySQL я обычно устанавливаю 256M или 512M. Вы должны поэкспериментировать с большими значениями, когда загрузка данных приводит к ошибкам «MySQL исчез».
max_allowed_packet900M, и я использовал--skip-extended-insert(и вы правы - это делает для huuuge db-dumps), но все равно не получается. Я подозреваю конкретную строку в дампе теперь, когда я, вероятно, могу обойти. Но это все еще странно - дамп можно нормально импортировать на мой сервер CentOS.Как долго это работает до истечения времени ожидания? Первый шаг поставил бы проверить
wait_timeoutиinteractive_timeoutнастройки , чтобы убедиться , что они достаточно велики для импорта:По умолчанию это 8 часов (28800), так что это не проблема. Другие указания на эту проблему можно найти здесь . Тот, который выделяется, это:
Сначала проверьте разрешения, но затем просмотрите список потенциальных проблем.
источник
Да, обычно игра с wait_timeout и max_allowed_packets позволяет мне обойти и сообщение об ошибке.
источник
Возможно, это не «правильная» вещь, но это может сработать (правильно?):
Попробуйте разбить большой дамп на несколько файлов и запускать их по очереди. Мой подход будет разбить его пополам и проверить. Затем разбейте каждую половину пополам, проведите повторное тестирование и так далее.
Мне несколько любопытно, может ли количество оперативной памяти, которое у вас есть на вашем устройстве, как-то связано с этим. Загружает ли MySQL весь дамп в память при запуске? Я не знаю ... но если у вас есть только 2 ГБ оперативной памяти, и часть ее используется под управлением вашей ОС и других приложений, то это может быть проблемой.
источник
Те, кто не имел успеха в других предложениях, могли бы рассмотреть вопрос о сценарии BigDump PHP в шахматном порядке импортер дампов MySQL .
Это обходной путь для импорта больших дампов базы данных в MySQL. Я успешно использовал его для импорта большого дампа MySQL в мою локальную среду разработки (в данном случае я использую MAMP).
источник