MySQL:: MySQL 8.0参考手册::7.5.2使用事件位置进行时间点恢复

版本8.0

5.7
5.6

8.0日本
5.6日本

MySQL 8.0参考手册/.．./ 使用事件位置进行时间点恢复

7.5.2通过事件位置进行时间点恢复

最后一节,第7.5.1节，“使用二进制日志进行时间点恢复”，解释了使用二进制日志执行某个时间点恢复的一般思想。本节通过一个示例详细解释该操作。

例如，假设2020年3月11日20:06:00左右，执行了一条删除表的SQL语句。可以执行某个时间点恢复，将服务器恢复到删除表之前的状态。以下是实现这一目标的一些示例步骤:

恢复在相关时间点之前创建的最后一个完整备份(调用它t_p在我们的例子中是2020年3月11日的20:06:00)。完成之后，注意您已经恢复服务器以供以后使用的二进制日志位置，并重新启动服务器。

请注意

而恢复的最后一个二进制日志位置也会在恢复和服务器重启后被InnoDB显示出来，即不这是获取恢复的结束日志位置的可靠方法，因为在显示的位置所反映的时间之后，可能会发生DDL事件和非innodb更改。您的备份和恢复工具应该为您提供恢复的最后一个二进制日志位置:例如，如果您正在使用mysqlbinlog对于该任务，检查二进制日志重播的停止位置;如果您正在使用MySQL企业备份，最后的二进制日志位置已经保存在您的备份中。看到时间点恢复．

找到与要恢复数据库的时间点对应的精确二进制日志事件位置。在我们的例子中，已知删除表的大致时间(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“DROP TABLE”/*80014集@@session.original_server_version = 80019 * / / * ! * /;/ * !80014集@@session.immediate_server_version = 80019 * / / * ! * /;设置@@SESSION。GTID_NEXT =‘匿名’/ * ! * /;# at 232 #200311 20:06:20 server id 1 end_log_pos 355 CRC32 0x2fc1e5ea查询thread_id=16 exec_time=0 error_code=0 SET TIMESTAMP=1583971580/*!*/;设置@@session.pseudo_thread_id = 16 / * ! * /;设置@@session。@@session foreign_key_checks = 1。@@session sql_auto_is_null = 0。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,删除表的“宠物”。“猫”语句可以在二进制日志段的行之间找到# 232而且# 355，这意味着声明发生了后日志位置为232，日志位置为355删除表声明。

请注意

只使用——start-datetime而且——stop-datetime选项，帮助您找到感兴趣的实际事件位置。不建议使用这两个选项指定要应用的二进制日志段的范围:在使用该选项时，丢失二进制日志事件的风险较高。使用——起始位置而且——停止位置代替。

将二进制日志文件中的事件应用到服务器，从第1步中找到的日志位置(假设它是155)开始，到第2步中找到的位置结束之前你感兴趣的时间点(即232):
```
$> mysqlbinlog——start-position=155——stop-position=232 /var/lib/mysql/bin。123456 \ | mysql -u root -p
```
该命令恢复从开始位置到停止位置之前的所有事务。因为的输出mysqlbinlog包括设置时间戳语句，恢复的数据和相关的MySQL日志反映事务执行的原始时间。
您的数据库现在已经恢复到您感兴趣的时间点，t_p就在桌子前面pets.cats是下降了。
在已经完成的时间点恢复之外，如果您还想重新执行所有语句后你感兴趣的时间点，使用mysqlbinlog再次应用之后的所有事件t_p到服务器。我们在步骤2中注意到，在我们想要跳过的语句之后，日志位于355的位置;我们可以用它来——起始位置选项，以便包含位置后面的任何语句:
```
$> mysqlbinlog——start-position=355 /var/lib/mysql/bin。123456 \ | mysql -u root -p
```
数据库已恢复为二进制日志文件中记录的最新语句，但已跳过所选事件。

上一页首页向上下一个