17.6.9.2. Восстановление момента времени Используя MySQL Cluster Replication

Восстановление момента времени — то есть, восстановление изменений данных, произведенных начиная с данного момента времени — выполняются после восстановления полного резервного копирования, которое возвращает сервер его состоянию, когда резервное копирование было сделано. Выполнение восстановления момента времени таблиц MySQL Cluster с MySQL Cluster и MySQL Cluster Replication может быть выполнено, используя собственное NDB резервное копирование данных (взятый, выходя CREATE BACKUP в ndb_mgm клиенте) и восстановление ndb_binlog_index таблица (от дампа, сделанного, используя mysqldump).

Чтобы выполнить восстановление момента времени MySQL Cluster, необходимо следовать за шагами, показанными здесь:

Поддержите все NDB базы данных в кластере, используя START BACKUP команда в ndb_mgm клиенте (см. Раздел 17.5.3, "Онлайновое Резервное копирование MySQL Cluster").
В некоторой более поздней точке, до восстановления кластера, делают резервное копирование mysql.ndb_binlog_index таблица. Является, вероятно, самым простым использовать mysqldump для этой задачи. Также поддержите двоичные файлы журнала в это время.

Это резервное копирование должно регулярно обновляться — возможно, даже ежечасно — в зависимости от Ваших потребностей.
(Катастрофический отказ или ошибка происходят.)
Определите местоположение последнего известного хорошего резервного копирования.
Очистите файловые системы узла данных (использующий ndbd --initial или ndbmtd --initial).

Отметить

Табличная область MySQL Cluster Disk Data и файлы журнала не удаляются --initial. Следует удалить их вручную.
Использовать DROP TABLE или TRUNCATE TABLE с mysql.ndb_binlog_index таблица.
Выполните ndb_restore, восстанавливая все данные. Следует включать --restore_epoch опция, когда Вы выполняете ndb_restore, так, чтобы ndb_apply_status таблица заполняется правильно. (См. Раздел 17.4.18, "ndb_restore — Восстановление MySQL Cluster Backup", для получения дополнительной информации.)
Восстановите ndb_binlog_index таблица от вывода mysqldump и восстановления двоичные файлы журнала от резервного копирования, в случае необходимости.
Сочтите эпоху примененной последний раз — то есть, максимум epoch значение столбца в ndb_apply_status таблица — как пользовательская переменная @LATEST_EPOCH (подчеркнутый):
```
SELECT @LAST_EPOCH:=MAX(epoch)     FROM mysql.ndb_apply_status;
```
Найдите последний двоичный файл журнала (@FIRST_FILE) и позиция (Position значение столбца) в пределах этого файла, которые соответствуют @LATEST_EPOCH в ndb_binlog_index таблица:
```
SELECT Position, @FIRST_FILE:=File     FROM mysql.ndb_binlog_index     WHERE epoch > @LAST_EPOCH ORDER BY epoch ASC LIMIT 1;
```
Используя mysqlbinlog, воспроизведите двоичные события журнала от брошенного файла и позиции на грани отказа. (См. Раздел 4.6.8, "mysqlbinlog — Утилита для Обработки Двоичных Файлов журнала".)

См. также Раздел 7.5, "Момент времени (Инкрементное) Восстановление Используя Двоичный Журнал", для получения дополнительной информации о двоичном журнале, репликации, и инкрементном восстановлении.