使用二进制日志进行时间点（增量）恢复
时间点恢复是指恢复自给定时间点以来所做的数据更改。通常，这种类型的恢复是在还原完整备份后执行的，该备份将使服务器在进行备份时进入其状态。（可以通过几种方式进行完全备份，例如“数据库备份方法”中列出的方式。）然后，时间点恢复将使服务器从完全备份时起逐步更新到最新状态。最近的时间。
注意这里的许多示例都使用mysql客户端来处理mysqlbinlog生成的二进制日志输出。如果您的二进制日志包含
\0（空）字符，则除非使用该选项调用它，否则mysql无法解析该输出--binary-mode。
时间点恢复的信息源是一组增量备份，这些增量备份由在完全备份操作之后生成的二进制日志文件表示。因此，必须使用--log-bin启用二进制日志记录的选项启动服务器（请参见“MySQL服务器二进制日志”）。
要从二进制日志还原数据，必须知道当前二进制日志文件的名称和位置。默认情况下，服务器在数据目录中创建二进制日志文件，但是可以使用--log-bin选项将路径名指定为将文件放置在其他位置。“二进制日志”。
要参见所有二进制日志文件的列表，请使用以下语句：
mysql>SHOW BINARYLOGS ;
要确定当前二进制日志文件的名称，请发出以下语句：
mysql>SHOW MASTER STATUS ;
该mysqlbinlog可以实用的二进制格式的二进制日志文件中的事件转换为文本，以便他们可以执行或参见。mysqlbinlog具有用于根据事件时间或事件在日志中的位置选择二进制日志部分的选项。请参见“mysqlbinlog-用于处理二进制日志文件的实用程序”。
从二进制日志执行事件会导致重做它们代表的数据修改。这样可以恢复给定时间范围内的数据更改。要执行二进制日志中的事件，请使用mysql客户端处理mysqlbinlog输出：
shell>mysqlbinlog binlog_files | mysql -u root -p
如果二进制日志文件已经过加密（可以从MySQL 8.0.14开始执行），则mysqlbinlog无法像上面的示例一样直接读取它们，但是可以使用--read-from-remote-server（-R）选项从服务器读取它们。例如：
shell>mysqlbinlog --read-from-remote-server --host=host_name --port=3306 --user=root --password --ssl-mode=required binlog_files | mysql -u root -p
在这里，该选项--ssl-mode=required已用于确保二进制日志文件中的数据在传输中受到保护，因为该数据是以未加密的格式发送到mysqlbinlog的。
当需要在执行事件之前确定事件时间或位置以选择部分日志内容时，参见日志内容会很有用。要从日志中参见事件，请将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的二进制日志中读回时写入转储文件时（请参见“使用全局事务标识符进行复制”），请将该--skip-gtids选项与mysqlbinlog一起使用，如下所示：
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"
使用事件时间进行时间点恢复
要指示恢复的开始时间和结束时间，请以格式指定mysqlbinlog的--start-datetime和--stop-datetime选项。例如，假设恰好在2005年4月20日上午10:00执行了一条删除大表的SQL语句。要还原表和数据，可以还原前一晚的备份，然后执行以下命令：DATETIME
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的时间来排除特定的更改效果不佳。
使用事件位置进行时间点恢复
代替指定日期和时间，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的输出SET TIMESTAMP在记录每个SQL语句之前都包含语句，因此恢复的数据和相关的MySQL日志将反映执行事务的原始时间。