9.5.2 Point-in-Time Recovery Using Event Positions — MySQL 8.4

9.5.2 Восстановление по состоянию на определённый момент времени с использованием позиций событий

В предыдущем разделе, разделе 9.5.1 «Восстановление по состоянию на определённый момент времени с использованием бинарного журнала», объясняется общая идея использования бинарного журнала для выполнения восстановления по состоянию на определённый момент времени. Раздел подробно описывает операцию с примером.

В качестве примера предположим, что около 20:06:00 11 марта 2020 года было выполнено оператор SQL, удаливший таблицу. Вы можете выполнить восстановление по состоянию на определённый момент времени, чтобы восстановить сервер до состояния непосредственно перед удалением таблицы. Вот примерные шаги для этого:

Восстановите последнюю полную резервную копию, созданную до интересующего момента времени (назовите его t_p, в нашем примере это 20:06:00 11 марта 2020 года). По завершении запишите позицию бинарного журнала, до которой вы восстановили сервер, для дальнейшего использования, и перезапустите сервер.

Примечание

Хотя последняя позиция бинарного журнала, восстановленная, также отображается InnoDB после восстановления и перезагрузки сервера, это не надёжный способ получения конечной позиции журнала восстановления, так как после времени, отражённого отображаемой позицией, могут произойти события DDL и изменения, не связанные с InnoDB. Ваша утилита резервного копирования и восстановления должна предоставить вам последнюю позицию бинарного журнала для вашего восстановления: например, если вы используете mysqlbinlog для этой задачи, проверьте позицию остановки воспроизведения бинарного журнала; если вы используете MySQL Enterprise Backup, последняя позиция бинарного журнала сохранена в вашем резервном копировании. См. .

Найдите точную позицию события бинарного журнала, соответствующую моменту времени, до которого вы хотите восстановить базу данных. В нашем примере, зная приблизительное время, когда произошло удаление таблицы (t_p), мы можем найти позицию журнала, проверив содержимое журнала вокруг этого времени с помощью утилиты mysqlbinlog. Используйте параметры --start-datetime и --stop-datetime для указания короткого временного периода вокруг t_p, а затем найдите событие в выводе. Например:

$> mysqlbinlog --start-datetime="2020-03-11 20:05:00" \
                   --stop-datetime="2020-03-11 20:08:00" --verbose \
         /var/lib/mysql/bin.123456 | grep -C 15 "DROP TABLE"
 
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 232
#200311 20:06:20 server id 1  end_log_pos 355 CRC32 0x2fc1e5ea 	Query	thread_id=16	exec_time=0	error_code=0
SET TIMESTAMP=1583971580/*!*/;
SET @@session.pseudo_thread_id=16/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
DROP TABLE `pets`.`cats` /* generated by server */
/*!*/;
# at 355
#200311 20:07:48 server id 1  end_log_pos 434 CRC32 0x123d65df 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=no	original_committed_timestamp=1583971668462467	immediate_commit_timestamp=1583971668462467	transaction_length=473
# original_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT)
# immediate_commit_timestamp=1583971668462467 (2020-03-11 20:07:48.462467 EDT)
/*!80001 SET @@session.original_commit_timestamp=1583971668462467*//*!*/;
/*!80014 SET @@session.original_server_version=80019*//*!*/;
/*!80014 SET @@session.immediate_server_version=80019*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 434
#200311 20:07:48 server id 1  end_log_pos 828 CRC32 0x57fac9ac 	Query	thread_id=16	exec_time=0	error_code=0	Xid = 217
use `pets`/*!*/;
SET TIMESTAMP=1583971668/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE dogs

Из вывода mysqlbinlog оператор DROP TABLE `pets`.`cats` можно найти в части бинарного журнала между строкой # at 232 и # at 355, что означает, что оператор выполняется после позиции журнала 232, и журнал находится в позиции 355 после оператора DROP TABLE.

Примечание

Используйте параметры --start-datetime и --stop-datetime только для поиска фактических позиций событий, которые вас интересуют. Использование этих двух параметров для указания диапазона сегмента бинарного журнала для применения не рекомендуется: существует большая вероятность пропуска событий бинарного журнала при использовании этих параметров. Используйте --start-position и --stop-position вместо этого.

Примените события в файле бинарного журнала к серверу, начиная с позиции журнала, найденной в шаге 1 (предположим, это 155), и заканчивая позицией, найденной в шаге 2, которая находится перед интересующим моментом времени (которое составляет 232):
```
$> mysqlbinlog --start-position=155 --stop-position=232 /var/lib/mysql/bin.123456 \
         | mysql -u root -p
```
Команда восстанавливает все транзакции с начальной позиции до позиции непосредственно перед позицией остановки. Поскольку вывод mysqlbinlog включает SET TIMESTAMP операторы перед каждым записанным оператором SQL, восстановленные данные и соответствующие журналы MySQL отражают исходное время выполнения транзакций.

Ваша база данных теперь восстановлена до интересующего момента времени, t_p, непосредственно перед удалением таблицы pets.cats.
Помимо восстановления по состоянию на определённый момент времени, если вы также хотите повторно выполнить все операторы после интересующего вас момента времени, используйте mysqlbinlog ещё раз, чтобы применить все события после t_p к серверу. В шаге 2 мы отметили, что после оператора, который мы хотели пропустить, журнал находится в позиции 355; мы можем использовать его для параметра --start-position, чтобы все операторы после этой позиции были включены:
```
$> mysqlbinlog --start-position=355 /var/lib/mysql/bin.123456 \
         | mysql -u root -p
```
Ваша база данных восстановлена до последнего оператора, записанного в файле бинарного журнала, но с пропуском выбранного события.