Неполный 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 сделать полный снимок базы данных?

РЕДАКТИРОВАТЬ: моя база данных в настоящее время находится на RDS Amazon.

Возможно, это была проблема с max_allowed_packetнедостаточно высокой настройкой как на клиенте (например, mysqldump), так и на сервере (например, Amazon RDS). Я установил это на 500M на обоих, и это, кажется , решило проблему.

Поскольку таблицы информационной схемы 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 -action --quick"?

Вполне возможно, что таблица повреждена. Я не имею в виду, что данные и / или страницы индекса повреждены. Там может быть что-то очень простое, что сломано.

Недавно у меня возникла проблема со сценарием резервного копирования на подчиненном сервере, когда я параллельно выполнял mysqldumped несколько баз данных. Запуск mysqldump на одной из баз данных привел к очень маленькому mysqldump. В БД было более 80 таблиц. Однако mysqldump остановился на пятой таблице в БД. Когда я побежал SHOW CREATE TABLE tblname\Gпо столу на ведомом устройстве, я получил ошибку «Таблица не найдена». Когда я побежал SHOW CREATE TABLE tblname\Gна Мастер, описание таблицы отображалось, как и ожидалось.

То, что произошло, было немного сумасшедшим: клиент попросил восстановить таблицу, а инженер восстановил файл .ibd таблицы InnoDB из резервной копии диска. Идентификатор табличного пространства файла .ibd (который был 25) не соответствовал идентификатору табличного пространства, зарегистрированному в ibdata1 (который был 28).

Я исправил проблему, закрыв подчиненное устройство, выполнив mysqldumping master и настроив репликацию с нуля. К счастью, общий объем данных и индекса составил 7 ГБ. Таким образом, процесс rstore не имеет большого значения.

МОРАЛЬ ИСТОРИИ

Основная проблема заключается в том, что 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, чтобы посмотреть, повлияет ли это на Amazon RDS (или Amazon увеличит этот лимит). Также попробуйте поэкспериментировать с дампом отдельных таблиц.

ОБНОВЛЕНИЕ 2011-11-14 17:58 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Попробуйте выполнить это в вашей сессии DB (установите на две минуты):

SET innodb_lock_wait_timeout = 120;