Сервер MySQL ушел, затрудняя импорт больших дампов

Я пытаюсь импортировать большой дамп sql (2 ГБ) в мой локальный mysql на моем Mac. Я мог сделать это в прошлом (я использовал MAMP), но теперь я получаю ОШИБКУ 2006 (HY000) в строке 7758. Сервер MySQL исчезал при каждой попытке импортировать дамп. База данных содержит таблицы innodb.

Я попытался скопировать файл my-innodb-heavy-4G.cnf в my.cnf, чтобы посмотреть, помогут ли эти настройки, но не повезло.

Любые идеи о том, что настроить?

Я использую «Mac OS X версии 10.6 (x86, 64-bit), DMG Archive» отсюда: http://dev.mysql.com/downloads/mysql/

Одним из тихих убийц 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 выполняются по одному. Основными недостатками являются

1. mysqldump намного больше
2. перезагрузка такой свалки занимает гораздо больше времени.

ПОДХОД № 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 исчез».

Как долго это работает до истечения времени ожидания? Первый шаг поставил бы проверить wait_timeoutи interactive_timeoutнастройки , чтобы убедиться , что они достаточно велики для импорта:

SHOW VARIABLES LIKE '%_timeout';
SET SESSION wait_timeout=28800;

По умолчанию это 8 часов (28800), так что это не проблема. Другие указания на эту проблему можно найти здесь . Тот, который выделяется, это:

Клиентское приложение, запущенное на другом хосте, не имеет необходимых прав для подключения к серверу MySQL с этого хоста.

Сначала проверьте разрешения, но затем просмотрите список потенциальных проблем.

Да, обычно игра с wait_timeout и max_allowed_packets позволяет мне обойти и сообщение об ошибке.

Возможно, это не «правильная» вещь, но это может сработать (правильно?):

Попробуйте разбить большой дамп на несколько файлов и запускать их по очереди. Мой подход будет разбить его пополам и проверить. Затем разбейте каждую половину пополам, проведите повторное тестирование и так далее.

Мне несколько любопытно, может ли количество оперативной памяти, которое у вас есть на вашем устройстве, как-то связано с этим. Загружает ли MySQL весь дамп в память при запуске? Я не знаю ... но если у вас есть только 2 ГБ оперативной памяти, и часть ее используется под управлением вашей ОС и других приложений, то это может быть проблемой.

Те, кто не имел успеха в других предложениях, могли бы рассмотреть вопрос о сценарии BigDump PHP в шахматном порядке импортер дампов MySQL .

Это обходной путь для импорта больших дампов базы данных в MySQL. Я успешно использовал его для импорта большого дампа MySQL в мою локальную среду разработки (в данном случае я использую MAMP).