5.2 Point-in-Time Recovery — MySQL Enterprise Backup 4.1

5.2 Восстановление по состоянию на определённую точку времени

Вы можете восстановить вашу базу данных до состояния на произвольный момент времени, используя файлы бинарного лога, включенные в резервные копии. Процесс предполагает выполнение следующих условий:

В резервируемом сервере MySQL включено ведение бинарного лога. Для проверки этого условия выполните следующую команду на сервере:
```
mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)
```
Если значение равно OFF, ведение бинарного лога не включено. См. для получения информации о включении ведения бинарного лога на сервере.
Для сервера создана серия резервных копий, обычно включающая полную резервную копию и ряд инкрементных резервных копий. Последняя резервная копия в серии охватывает целевую точку времени для восстановления. Приведенный ниже пример иллюстрирует типичный случай.
Последняя резервная копия в серии резервных копий включает в себя соответствующие файлы бинарного лога. (Чтобы убедиться в выполнении этого требования, не используйте следующие опции MySQL Enterprise Backup при создании резервной копии: --skip-binlog, --use-tts, --no-locking или --start-lsn.)

Вот шаги для восстановления по состоянию на определённую точку времени:

Восстановите серию резервных копий на сервере, за исключением последней инкрементной резервной копии в серии (которая охватывает целевую точку времени для восстановления). По завершении, обратите внимание на позицию бинарного лога, до которой вы восстановили сервер. Информация доступна в файле backup_variables.txt в восстановленном каталоге данных сервера: найдите значение записи binlog_position в файле. Например:
```
binlog_position=binlog.000012:426
```
Это означает, что после восстановления серии резервных копий сервер находится в позиции лога 426, найденной в файле бинарного лога binlog.000012. Вам понадобится эта информация позже.

Примечание

Хотя последняя позиция бинарного лога, восстановленная, также отображается InnoDB после восстановления, это не надёжный способ получения конечной позиции лога восстановления, так как после времени, отражённого отображаемой позицией, могут произойти события DDL и изменения, не относящиеся к InnoDB.
Извлеките бинарный лог из последней инкрементной резервной копии в серии резервных копий (то есть резервной копии, которая охватывает целевую точку времени для восстановления). Это делается путем распаковки образа инкрементной резервной копии в каталог резервной копии, используя команду image-to-backup-dir; например:
```
mysqlbackup --backup-dir=incr-backup-dir2 --backup-image=incremental_image2.bi image-to-backup-dir
```
Затем перейдите в результирующий каталог резервной копии (incr-backup-dir2 в этом примере) и найдите файлы бинарного лога (binlog.000012 в этом примере) в каталоге данных:
```
incr-backup-dir2$ ls datadir
binlog.000012       ibbackup_logfile  mysql               pets      undo_002
...
```
Проведите пошаговое восстановление базы данных до состояния на целевую точку времени, идентифицированную как tR в данном примере, используя файл бинарного лога, извлечённый на последнем шаге. Затем, с помощью утилиты, воспроизведите на сервере SQL-действия, записанные в файле бинарного лога, начиная с позиции лога, до которой был восстановлен сервер на шаге 1 (это 426 в нашем примере), до времени tR. Укажите диапазон событий бинарного лога для воспроизведения, используя опцию --start-position и опцию --stop-position (которая указывает соответствующую позицию бинарного лога для tR), и передайте вывод в клиент mysql:
```
mysqlbinlog --start-position="binary-log-position-at-the-end-of-backup-restores" \
         --stop-position="binary-log-position-corresponding-to-tR" \
         binary-log-filename  |   mysql -uadmin -p
```
Примечания
- Использование опции --start-datetime или --stop-datetime для указания диапазона сегмента бинарного лога для воспроизведения не рекомендуется: существует более высокий риск пропуска событий бинарного лога при использовании этой опции. Используйте --start-position и --stop-position вместо этого.
- Если у вас более одного файла бинарного лога в инкрементной резервной копии и все они необходимы для приведения сервера в состояние на tR, необходимо передать их все на сервер в одном соединении; например:
  mysqlbinlog --start-position="426" --stop-position="binary-log-position-corresponding-to-tR" \ binlog.000012 binlog.000013 binlog.000014 | mysql -u admin -p
Вы также можете сначала сохранить весь вывод mysqlbinlog в один файл, а затем передать или воспроизвести этот файл в клиент mysql.

Дополнительные объяснения использования бинарного лога для восстановления по состоянию на определенную точку времени можно найти в .
Проверьте, был ли сервер восстановлен до желаемой точки во времени.