7.5. Момент времени (Инкрементное) Восстановление Используя Двоичный Журнал

7.5.1. Восстановление момента времени Используя Времена События
7.5.2. Восстановление момента времени Используя Позиции События

Восстановление момента времени обращается к восстановлению изменений данных, произведенных начиная с данного момента времени. Как правило, этот тип восстановления выполняется после восстановления полного резервного копирования, которое приносит сервер к его состоянию со времени, которым было сделано резервное копирование. (Полное резервное копирование может быть сделано несколькими способами, такими как перечисленные в Разделе 7.2, "Методы Резервного копирования базы данных".) Восстановление Момента времени тогда осовременивает сервер с приращением со времени полного резервного копирования к более свежему времени.

Восстановление момента времени основано на этих принципах:

Источник информации для восстановления момента времени является набором инкрементных резервных копий, представленных двоичными файлами журнала, сгенерированными последующий за полной операцией резервного копирования. Поэтому, сервер должен быть запущен с --log-bin опция, чтобы включить двоичному журналированию (см. Раздел 5.2.4, "Двоичный Журнал").

Чтобы восстановить данные от двоичного журнала, следует знать название и местоположение текущих двоичных файлов журнала. По умолчанию сервер создает двоичные файлы журнала в каталоге данных, но путь может быть определен с --log-bin опция, чтобы поместить файлы в различное расположение. Раздел 5.2.4, "Двоичный Журнал".

Чтобы видеть перечисление всех двоичных файлов журнала, используйте этот оператор:
```
mysql> SHOW BINARY LOGS;
```
Чтобы определить имя текущего двоичного файла журнала, сделайте следующее заявление:
```
mysql> SHOW MASTER
                    STATUS;
```
mysqlbinlog утилита преобразовывает события в двоичных файлах журнала от двоичного формата до текста так, чтобы они могли быть выполнены или просмотрены. у mysqlbinlog есть опции для того, чтобы выбрать разделы двоичного журнала, основанного на временах события или позиции событий в пределах журнала. См. Раздел 4.6.8, "mysqlbinlog — Утилита для Обработки Двоичных Файлов журнала".
Выполнение событий от двоичного журнала вызывает модификации данных, которые они представляют, чтобы быть сделанными заново. Это включает восстановлению изменений данных для данного промежутка времени. Чтобы выполнить события от двоичного журнала, обработайте вывод mysqlbinlog, используя mysql клиент:
```
shell> mysqlbinlog binlog_files | mysql -u root -p
```
Просмотр содержания журнала может быть полезным, когда Вы должны определить времена события или позиции, чтобы выбрать частичное содержание журнала до выполняющихся событий. Чтобы просмотреть события от журнала, отправьте вывод mysqlbinlog в программу оповещения:
```
shell> mysqlbinlog binlog_files | more
```
Альтернативно, сохраните вывод в файле и просмотрите файл в текстовом редакторе:
```
shell> mysqlbinlog binlog_files > tmpfileshell> ... edit tmpfile ...
```
Сохранение вывода в файле полезно как предварительное мероприятие перед выполнением содержания журнала с определенными удаленными событиями, такими как случайный элемент DROP DATABASE. Можно удалить из файла любые операторы, которые не будут выполняться прежде, чем выполнить его содержание. После редактирования файла выполните содержание следующим образом:
```
shell> mysql -u root -p <
                    tmpfile
```

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

shell> mysqlbinlog binlog.000001 | mysql -u root -p #
        DANGER!!shell> mysqlbinlog binlog.000002 | mysql -u root -p #
        DANGER!!

Обработка двоичного файла регистрирует этот способ использовать различные соединения с проблемами причин сервера, если первый файл журнала содержит a CREATE TEMPORARY TABLE оператор и второй журнал содержат оператор, который использует временную таблицу. Когда первый процесс mysql завершается, сервер отбрасывает временную таблицу. Когда второй процесс mysql пытается использовать таблицу, отчеты сервера "неизвестная таблица."

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

shell> mysqlbinlog binlog.000001 binlog.000002 |
        mysql -u root -p

Другой подход должен записать все журналы в единственный файл и затем обработать файл:

shell> mysqlbinlog binlog.000001 >
        /tmp/statements.sqlshell> mysqlbinlog binlog.000002 >>
        /tmp/statements.sqlshell> mysql -u root -p -e "source
        /tmp/statements.sql"