Неповний mysqldump

Я намагаюся запустити mysqldump, щоб створити знімок бази даних, і я знаходжу, що він випадково зупиниться посередині, не повідомляючи про помилку. Моя база даних порівняно невелика (близько 100 Мб) і використовує InnoDB.

Я запускаю це так:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Перевірка вихідного коду повідомляє 0.

Моя версія: mysqldump Ver 10.13 Distrib 5.1.52, для redhat-linux-gnu (i386)

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

Як змусити mysqldump зробити повний знімок бази даних?

EDIT: Моя база даних наразі знаходиться на RDS Amazon.

Можливо, це була проблема з max_allowed_packetнедостатнім встановленням як клієнта (тобто mysqldump), так і сервера (тобто Amazon RDS). Я встановив це на 500 мільйонів обох, і, здається , виправили проблему.

Оскільки таблиці інформаційних схем InnoDB дають лише оцінки кількості рядків, важко сказати, чи справді мій знімок включає все, що складається з RDS. Усі таблиці є, але кількість рядків відрізняється. Я оновлюсь більш чіткою відповіддю, коли матиму час для більш детального аналізу сценарію.

Ти намагався?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

Це простий спосіб, коли я це завжди роблю без проблем. В основному, роблячи дамп таким чином, ви отримуєте все, що у вас є (дані, об’єкти та іноді дорогоцінні коментарі) в певний момент, ігноруючи невдалі транзакції.

Наскільки я розумію, mysql docs --single-транзакції не вдасться, якщо зчитування виконується на столі під час демпінгу. Який результат при запуску без "--force --single-транзакції --quick"?

Цілком можливо, що стіл зіпсований. Я не маю на увазі, що дані та / або покажчики пошкоджені. Можливо, щось дуже просте, що порушено.

Нещодавно у мене виникли проблеми із сценарієм резервного копіювання на Slave Server, коли я паралельно виконував декілька баз даних. Запуск mysqldump на одній з баз даних призвів до дуже невеликого mysqldump. У БД було 80+ таблиць. Однак mysqldump зупинився на п’ятій таблиці в БД. Коли я побіг SHOW CREATE TABLE tblname\Gза столом на Рабі, я отримав помилку "Таблиця не знайдена". Коли я біг SHOW CREATE TABLE tblname\Gна Майстер, опис таблиці відображався як очікувалося.

Що сталося, було трохи шалено: Клієнт попросив відновити таблицю, а інженер відновив .ibd файл таблиці InnoDB з резервної копії диска. Ідентифікатор простору таблиць .ibd-файлу (якого було 25) не збігався з ідентифікатором простору таблиць, зареєстрованим у ibdata1 (що було 28).

Я вирішив проблему, ввімкнувши підлеглого, замисливши майстра і налаштувавши реплікацію з нуля. На щастя, обсяг даних та індексу склав 7 Гб. Таким чином, процес реставрації не був великим завданням.

МОРАЛ ІСТОРІЇ

Основна проблема полягає в тому, що mysqldump не повідомляє про помилку на InnoDB, коли ідентифікатор просторової таблиці невірний. Коли mysqldump закінчується і не скидає кожну таблицю в алфавітному порядку, це вказує, що вона припиняється помилкою, і це робиться без друку повідомлення про помилку.

Перевірте, щоб переконатися

• ви можете відобразити структуру таблиці за допомогою SHOW CREATE TABLE
• Ви можете запитати все про таблицю з INFORMATION_SCHEMA.TABLES

Нижче наведено лише певний мозковий штурм на mysqldump та InnoDB:

Подумайте, будь ласка, про поведінку mysqldump щодо таблиці InnoDB. Якщо в буферному басейні InnoDB є якісь брудні сторінки, що належать до таблиці, яку ви скидаєте, брудні сторінки цієї таблиці повинні бути видалені на диск, перш ніж банк SELECT /* SQL_NO_CACHE */може бути виконаний проти неї.

Оскільки ви використовуєте Amazon RDS, я відчуваю, що ваша база даних перебуває у багатосторонній інфраструктурі (не соромтеся виправити це твердження, якщо я надто спрощую це). Інші бази даних можуть використовувати спільний буфер InnoDB, спільний файл метаданих (ibdata1) та спільний простір таблиць (ibdata1, якщо innodb_file_per_table вимкнено).

Також може відбуватися деяка надмірність бази даних, що може вплинути на MVCC щодо бази даних, навіть якщо це невеликий набір даних.

Ви можете захотіти збільшити innodb_lock_wait_timeout (за замовчуванням 50 секунд) під час сеансу mysqldump, щоб побачити, чи це впливає на RDS Amazon (чи Амазонка збільшить цю межу). Також спробуйте експериментувати з демпінгом окремих таблиць.

ОНОВЛЕННЯ 2011-11-14 17:58 EDT

Спробуйте виконати це в межах сесії БД (встановлює його на дві хвилини):

SET innodb_lock_wait_timeout = 120;