MySQL-сервер пішов, перешкоджаючи імпорту великих звалищ

Я намагаюся імпортувати великий sql-дамп (2 Гб) до мого локального mysql на своєму mac. Мені це було вдається раніше (я використовував MAMP), але тепер я отримую ПОМИЛУ 2006 (HY000) у рядку 7758: сервер MySQL відходив кожного разу, коли я намагаюся імпортувати дамп. База даних містить таблиці innodb.

Я спробував скопіювати файл my-innodb-heavy-4G.cnf в мій my.cnf, щоб побачити, чи допоможуть ці налаштування, але не пощастило.

Будь-які ідеї щодо того, що підкрутити?

Я використовую "Mac OS X ver. 10.6 (x86, 64-бітний), DMG Archive" звідси: http://dev.mysql.com/downloads/mysql/

Одним із безшумних вбивць MySQL Connections є пакет MySQL. Навіть нитка вводу-виводу реплікації MySQL може стати жертвою цього.

Відповідно до документації MySQL

• Ви також можете отримати ці помилки, якщо надішлете запит на сервер, який є неправильним або занадто великим. Якщо mysqld отримує занадто великий пакет або вийшов із ладу, він припускає, що з клієнтом щось пішло не так і закриває з'єднання. Якщо вам потрібні великі запити (наприклад, якщо ви працюєте з великими стовпцями BLOB), ви можете збільшити ліміт запитів, встановивши змінну max_allowed_packet на сервері, яка має значення за замовчуванням 1МБ. Можливо, вам також знадобиться збільшити максимальний розмір пакета на клієнтському кінці. Більш детальну інформацію про встановлення розміру пакета наведено у Розділі C.5.2.10, "Пакет занадто великий".

• Заява INSERT або REPLACE, яка вставляє велику кількість рядків, також може спричинити подібні помилки. Будь-яке з цих висловлювань надсилає сервер один запит незалежно від кількості рядків, які потрібно вставити; таким чином, ви часто можете уникнути помилки, зменшивши кількість рядків, надісланих на INSERT або ЗАМІНУ.

По крайней мере, ви повинні переконатися, що розміри пакетів для машини, з якої мишклдамп'од, і машини, яку ви завантажуєте, однакові.

Ви можете скористатися двома (2) підходами:

ДОДАТОК №1: Виконайте mysqldump, використовуючи --skip-extension-insert

Це дозволить переконатися, що пакет MySQL не завалений кількома полями BLOB, TEXT. Таким чином SQL INSERT виконуються по одному. Основні недоліки є

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

ПІДХІД №2: Збільшити max_allowed_packet

Це може бути кращим підходом, оскільки реалізація цього завдання - лише перезапуск mysql. Розуміння того, що таке MySQL Packet, може пояснити це.

Відповідно до сторінки 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 Гб оперативної пам’яті, а деякі з них використовуються під керуванням вашої ОС та інших програм, то це може бути проблемою.

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

Це вирішення для імпорту великих скидів баз даних у MySQL. Я успішно використовував його для імпорту великого дампа MySQL у моє місцеве середовище розробки (я використовую MAMP у цьому випадку).