Стратегия восстановления поврежденной таблицы в MySQL

Спасибо за методику. Не дай бог воспользоваться, но береженого Бог бережет.

Люблю такие статьи, спасибо.
Обычно к ним комментариев мало, но все добавляют в избранное.
Как гайд на будущее, если его случится.
Зато спокоен, знаешь, что на Хабре лежит и искать долго не придется.

Интересно конечно. Но, позволь расскажу другую историю (может пригодится) у меня используется просто тупой метод копирования (данных не очень много проект не особо крупный). В момент разработки системы, чтобы сэкономить время таблицы myisam тупо копируются в файловое хранилище причем не за один день, а за целый месяц, вернее в имени каждого архива имеется дата. В случае существования такого архива он перезаписывается. Поскольку таблицы myisam, а именно файлы .MYD, .frm и .MYI можно спокойно копировать сохраняя их целостность, соответственно точно так же и восстанавливать, они копируются, архивируются и лежат ждут своей участи. Может так больше места тратится, но быстрее и проще.
P.S. С таблицами innoDB так к сожалению не прокатит.

1. У вас присутствует одна неточность, которая может серьёзно подпортить вам жизнь. В бинлог попадают записи как
use ACME;
update/insert blah blah
так и
USE DB2;
update ACME.tablename

mysqlbinlog -d ACME_DB <бинарный лог> | mysql -u increment -p ACME_DB_INCREMENTAL
выведет конструкции с дефолтной базой только, пропустив
update ACME.tablename;

В официальной доке по mysqlbinlog пример расписан
dev.mysql.com/doc/refman/5.0/en/mysqlbinlog.html

2. Для целостного бэкапа рекоменду поднимать реплику mysql, с которой легко можно сделать целостный бэкап остановив репликацию.