Нужно восстановить удаленную InnoDB таблицу.

[IVB]

Доброго времени суток, дамы и господа.

 

Нужно восстановить удаленную (DROP TABLE) InnoDB таблицу.

 

Есть файлы таблица.frm и таблица.ibd (опция file_per_table включена) с данными почти на момент удаления.

 

Попытался создать пустую базу, в ней создать именно эти таблицы, и затем подменить файлы (чтобы получить "нормальный" бэкап). С MyISAM такое проходит "на ура", но InnoDB отказывается видеть файлы таблиц (вплоть до краха Мускуля).

 

Если кто-то уже решал подобные задачи - поделитесь рецептом.

[QWE]

скорее всего только из дампа если делали, движок InnoDB это гемморой.

[ixi]

таблица.ibd содержит id таблицы, при несовпадении выдаётся ошибка. Метод достаточно прост:

- Создаётся новая БД;

- создаётся новая таблица того же формата;

- alter table test discard tablespace;

- заменяется .ibd;

- alter table test import tablespace;

- в логах текущий(1) и ожидаемый id(n)

- создать (n-2) пустых таблиц

- создать нужную таблицу, discard/.idb/import как выше

- дамп

[IVB]

скорее всего только из дампа если делали, движок InnoDB это гемморой.

Дамп не делали, т.к. все базы с мастера реплицируются на слейв (т.е. для случая отказа оборудования - бэкап идеальный).

 

Прийдется еще и дамп дополнительно настраивать, чтобы от собственных "кривых рук" защититься (удалял ненужную таблицу и "промахнулся") :(

[QWE]

скорее всего только из дампа если делали, движок InnoDB это гемморой.

Дамп не делали, т.к. все базы с мастера реплицируются на слейв (т.е. для случая отказа оборудования - бэкап идеальный).

 

Прийдется еще и дамп дополнительно настраивать, чтобы от собственных "кривых рук" защититься (удалял ненужную таблицу и "промахнулся") :(

"Промахнулся"

Получается что режим работы Мастер - Слейв обладает существенным недостатком. Поэтому делать дампы и хранить их подальше в нескольких местах

[NiTr0]

Получается что режим работы Мастер - Слейв обладает существенным недостатком.

Какой такой недостаток? Что резервирование не заменяет собой резервное копирование? Так это и так понятно.

Суть резервирования - держать макисмально актуальные данные на резервном хранилище при отказе основного. Версионирование и т.п. - вторично.

 

В теории - вроде как по бинлогу (если не чистился) можно воссоздать любое состояние БД, но на практике...

[IVB]

таблица.ibd содержит id таблицы, при несовпадении выдаётся ошибка. Метод достаточно прост:

- Создаётся новая БД;

- создаётся новая таблица того же формата;

- alter table test discard tablespace;

- заменяется .ibd;

- alter table test import tablespace;

- в логах текущий(1) и ожидаемый id(n)

- создать (n-2) пустых таблиц

- создать нужную таблицу, discard/.idb/import как выше

- дамп

 

А "поковыряться" в .ibd hex-редактором и "подправить" id возможно? Структура файлов .ibd где-нибудь расписана?

[ixi]

А "поковыряться" в .ibd hex-редактором и "подправить" id возможно? Структура файлов .ibd где-нибудь расписана?

id находится в заголовке каждой страницы файла. а так http://dev.mysql.com/doc/internals/en/innodb-page-structure.html

[QWE]

Получается что режим работы Мастер - Слейв обладает существенным недостатком.

Какой такой недостаток? Что резервирование не заменяет собой резервное копирование? Так это и так понятно.

Суть резервирования - держать макисмально актуальные данные на резервном хранилище при отказе основного. Версионирование и т.п. - вторично.

 

Таким образом привлекаю внимание 'IVB' к

 

"Дамп не делали, т.к. все базы с мастера реплицируются на слейв (т.е. для случая отказа оборудования - бэкап идеальный)."

 

Горячий резерв - конечно же это не бекап. Это защита от остановки/исчезновения узла/ноды, с минимальным временем простоя и потерей данных.

[vitalyb]

У меня база была не "файлы россыпью" (т.е. при дропе таблицы физически файл не удаляется, а остается кусками в ibdata), восстанавливал с помощью http://www.percona.com/software/mysql-innodb-data-recovery-tools

[st_re]

Да методы вернуть удаленную таблицу при сохранившихся файлах - есть. НО так бывает не всегда. Обычно файл уходит.

ну завтра ктото напишет delete from <table>; без where.. Или условие неверное. Или еще 100500 разных вариантов. Бакап нужен. Да, при наличии реплики вероятность дойти до необходимости поднятия с бакапа немного снижается. но не более того.

[vitalyb]

Да, при наличии реплики вероятность дойти до необходимости поднятия с бакапа немного снижается. но не более того.

Не снижается она: восстанавливается бакап + воспроизводится журнал запросов из бинлога до "фатального".

 

Да, кстати, бакап тоже надо делать правильно, чтобы потом не было мучительно больно при поиске места откуда же надо этот журнал воспроизводить.

Edited August 30, 2013 by vitalyb

[QWE]

http://company.yandex.ru/job/vacancies/monitoring_operator_srv.xml

4 вопрос

[st_re]

ну таки умершая дисковая система запросто уносит и бинлоги. Ага.. А на реплике они уже есть.. Опять же свапнуть слейв в мастер и не торопясь восстанавливать сдохший сервер таки быстрее, чем просто восстанавливать сервер, потом восстанавливать базу, потом туда логи.. Сдохший мастер ставится слейвом к новому мастеру.. если машинки не равнозначные по мощности то опять свапается мастер-слейв. Простои минимальны. Это как 1 или 5 рейд. Сдохший диск заменяется.. но не помогает от удаления файлов, сдыхания более чем одного диска или пожара в ДЦ.

 

А делая бакап неплохо бы время от времени тренироваться оттуда восстанавливаться на тестовой машинке/площадке :) Чтобы убедиться, что данные таки бакапятся, что бакапятся все данные и что мы в курсе как этим потом воспользоваться :) А то инструкция по восстановлению с бакапа осталась только на бакапе :)

[YuryD]

А делая бакап неплохо бы время от времени тренироваться оттуда восстанавливаться на тестовой машинке/площадке :) Чтобы убедиться, что данные таки бакапятся, что бакапятся все данные и что мы в курсе как этим потом воспользоваться :) А то инструкция по восстановлению с бакапа осталась только на бакапе :)

 

Тут скорее иное может приключиться, не хватает например места на fs :)Да и время разворота из tgz бакапа во много гиг - тоже не маленькое. Пользую mysqlhotcopy, пару раз не удалось оперативно подняться... Пришлось дневной бакап сразу перекидывать на резервный сервер.