参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html

时间点恢复是指恢复自给定时间点以来所做的数据更改。 通常，这种类型的恢复是在恢复完整备份后执行的，该备份会将服务器恢复到备份完成时的状态。 （完整备份可以通过多种方式进行，例如第7.2节“数据库备份方法”中列出的那些方法）。时间点恢复使服务器从完全备份时间开始逐步更新到最近时间。

注意：

这里的许多示例使用mysql客户端来处理由mysqlbinlog生成的二进制日志输出。 如果您的二进制日志包含\ 0（null）字符，则该输出不能被mysql解析，除非您使用--binary-mode选项调用该输出。

时间点恢复基于以下原则：

• 时间点恢复信息的来源是由完整备份操作后生成的二进制日志文件所代表的一组增量备份。 因此，必须使用--log-bin选项启动服务器以启用二进制日志记录

要从二进制日志中恢复数据，您必须知道当前二进制日志文件的名称和位置。 默认情况下，服务器会在数据目录中创建二进制日志文件，但可以使用--log-bin选项指定路径名以将文件放置在不同的位置。

要查看所有二进制日志文件的列表，请使用以下语句：

mysql> SHOW BINARY LOGS;

要确定当前二进制日志文件的名称，请发出以下语句：

mysql> SHOW MASTER STATUS;

• mysqlbinlog实用程序将二进制日志文件中的事件从二进制格式转换为文本，以便可以执行或查看它们。 mysqlbinlog有根据事件时间或日志内事件的位置选择二进制日志部分的选项。
• 从二进制日志中执行事件会导致它们所代表的数据修改。 这使得能够在给定的时间范围内恢复数据更改。 要从二进制日志中执行事件，请使用mysql客户端处理mysqlbinlog输出：

shell> mysqlbinlog binlog_files | mysql -u root -p

• 当您需要确定事件时间或位置以在执行事件之前选择部分日志内容时，查看日志内容可能很有用。 要查看日志中的事件，请将mysqlbinlog输出发送到分页程序中：

shell> mysqlbinlog binlog_files | more

• 当您需要确定事件时间或位置以在执行事件之前选择部分日志内容时，查看日志内容可能很有用。 要查看日志中的事件，请将mysqlbinlog输出发送到分页程序中：

shell> mysqlbinlog binlog_files | more

或者，将输出保存在文件中并在文本编辑器中查看该文件：

shell> mysqlbinlog binlog_files > tmpfile

shell> ... 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!!

如果第一个日志文件包含CREATE TEMPORARY TABLE语句，并且第二个日志包含使用临时表的语句，则以这种方式使用到服务器的不同连接处理二进制日志会导致问题。 当第一个mysql进程终止时，服务器删除临时表。 当第二个mysql进程尝试使用该表时，服务器会报告“未知表”。

为避免这样的问题，请使用单个连接来执行您要处理的所有二进制日志的内容。 这是一种方法：

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

另一种方法是将所有日志写入单个文件，然后处理该文件：

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

在从包含GTID的二进制日志回读时写入转储文件（请参见第16.1.3节“使用全局事务标识符进行复制”）时，请使用带mysqlbinlog的--skip-gtids选项，如下所示：

shell> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql

shell> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql

shell> mysql -u root -p -e "source /tmp/dump.sql"

7.5.1 使用事件事件进行时间点的恢复

要指示恢复的开始和结束时间，请为DATETIME格式指定mysqlbinlog的--start-datetime和--stop-datetime选项。 例如，假设恰好在2005年4月20日上午10点执行了一条删除大表的SQL语句。 要恢复表和数据，可以恢复前一夜的备份，然后执行以下命令：

shell> mysqlbinlog --stop-datetime="2005-04-20 9:59:59" /var/log/mysql/bin.123456 | mysql -u root -p

该命令将恢复所有数据，直到由--stop-datetime选项给出的日期和时间。 如果您未检测到数小时后输入的错误SQL语句，那么您可能还想要恢复之后发生的活动。 基于此，您可以使用开始日期和时间再次运行mysqlbinlog，如下所示：

shell> mysqlbinlog --start-datetime="2005-04-20 10:01:00" /var/log/mysql/bin.123456 | mysql -u root -p

在这个命令中，从上午10:01开始记录的SQL语句将被重新执行。 恢复前一天的转储文件和两个mysqlbinlog命令的组合可以恢复所有内容，直到上午10:00之前的一秒钟以及上午10:01上午的所有内容。

要使用这种时间点恢复方法，您应该检查日志以确保为命令指定的确切时间。 要显示日志文件内容而不执行它们，请使用以下命令：

shell> mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

然后用文本编辑器打开/tmp/mysql_restore.sql文件来检查它。

如果多个语句与要排除的语句同时执行，那么通过指定mysqlbinlog的时间排除特定更改不会有效。

7.5.2 使用事件位置来进行时间点的恢复

可以使用mysqlbinlog的--start-position和--stop-position选项来指定日志位置，而不是指定日期和时间。 除了指定日志位置编号而不是日期之外，它们的工作方式与开始日期和停止日期选项相同。 使用位置可以使您更精确地确定要恢复的日志的哪一部分，特别是如果许多事务与损坏的SQL语句大致同时发生。 要确定位置编号，请在执行不需要的事务时接近运行mysqlbinlog一段时间，但将结果重定向到文本文件以供检查。 这可以这样做：

shell> mysqlbinlog --start-datetime="2005-04-20 9:55:00" \ --stop-datetime="2005-04-20 10:05:00" \ /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

此命令在/tmp目录中创建一个小文本文件，该文件包含执行有害SQL语句时的SQL语句。 用文本编辑器打开此文件，并查找您不想重复的语句。 确定二进制日志中停止和恢复恢复的位置并记录它们。 位置被标记为log_pos后跟一个数字。 恢复以前的备份文件后，请使用位置编号来处理二进制日志文件。 例如，你可以使用类似这样的命令：

shell> mysqlbinlog --stop-position=368312 /var/log/mysql/bin.123456 | mysql -u root -p shell> mysqlbinlog --start-position=368315 /var/log/mysql/bin.123456 | mysql -u root -p

第一条命令恢复所有事务，直到给出停止位置。 第二个命令从给定的起始位置恢复所有事务，直到二进制日志结束。 由于mysqlbinlog的输出包括每个SQL语句记录之前的SET TIMESTAMP语句，因此恢复的数据和相关的MySQL日志将反映事务执行的原始时间。