7.5.1 使用二进制日志进行时间点恢复

本节说明使用二进制日志执行时间点恢复的一般思路。下一节第 7.5.2 节“使用事件位置进行时间点恢复”通过示例详细说明了该操作。

时间点恢复的信息源是在完全备份操作之后生成的二进制日志文件集。因此，要使服务器恢复到某个时间点，必须在其上启用二进制日志记录(有关详细信息，请参见第 5.4.4 节“二进制日志”)。

要从二进制日志还原数据，必须知道当前二进制日志文件的名称和位置。默认情况下，服务器在数据目录中创建二进制日志文件，但是可以使用--log-bin选项指定路径名以将文件放置在其他位置。要查看所有二进制日志文件的列 table，请使用以下语句：

mysql> SHOW BINARY LOGS;

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

mysql> SHOW MASTER STATUS;

mysqlbinlogUtil 将二进制日志文件中的事件从二进制格式转换为文本，以便可以查看或应用它们。 mysqlbinlog具有用于根据事件时间或事件在日志中的位置选择二进制日志的各个部分的选项。参见第 4.6.7 节“ mysqlbinlog-处理二进制日志文件的 Util”。

应用来自二进制日志的事件将导致重新执行它们 table 示的数据修改。这样可以恢复给定时间范围内的数据更改。要应用二进制日志中的事件，请使用mysqlClient 端处理mysqlbinlog输出：

shell> mysqlbinlog binlog_files | mysql -u root -p

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

shell> mysqlbinlog binlog_files | more

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

shell> mysqlbinlog binlog_files > tmpfile
shell> ... edit tmpfile ...

将输出保存在文件中对于在删除某些事件(例如意外DROP TABLE)时执行日志内容的准备工作很有用。您可以从文件中删除任何不执行的语句，然后再执行其内容。编辑文件后，按如下所示应用内容：

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

如果第一个日志文件包含创建临时 table语句，第二个日志包含使用临时 table 的语句，则使用与服务器的不同连接以这种方式处理二进制日志会引起问题。当第一个mysql进程终止时，服务器将删除临时 table。当第二个mysql进程尝试使用该 table 时，服务器报告“未知 table”。

为避免出现此类问题，请使用单个连接来应用要处理的所有二进制日志文件的内容。这是一种方法：

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 节“使用全局事务标识符进行复制”)，请将--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"