。

如果您的二进制日志包含\0#xff08;null#xff09;字符#xff0c;那么mysql将无法解析该输出#xff0c;除非您使用--binary模式选项调用它。

…一、

本节和下一节中的许多示例都使用mysql客户端来处理mysqlbinlog生成的二进制日志输出。

如果您的二进制日志包含\0null字符那么mysql将无法解析该输出除非您使用--binary模式选项调用它。

时间点恢复的信息源是在完全备份操作之后生成的一组二进制日志文件。

因此为了允许服务器恢复到某个时间点必须在其上启用二进制日志记录这是MySQL

要从二进制日志中恢复数据您必须知道当前二进制日志文件的名称和位置。

默认情况下服务器在数据目录中创建二进制日志文件但可以使用--log-bin选项指定路径名以将文件放置在不同的位置。

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

mysql

mysqlbinlog实用程序将二进制日志文件中的事件从二进制格式转换为文本以便可以查看或应用它们。

mysqlbinlog具有根据事件时间或事件在日志中的位置选择二进制日志部分的选项。

应用二进制日志中的事件会导致重新执行它们所表示的数据修改。

这样可以在给定的时间段内恢复数据更改。

要应用二进制日志中的事件请使用mysql客户端处理mysqlbinlog输出

mysqlbinlog

8.0.14开始则mysqlbinlog不能像上面的示例那样直接读取它们而是可以使用--read

from

moderequired用于确保二进制日志文件中的数据在传输过程中受到保护因为它是以未加密的格式发送到mysqlbinlog的。

对于SSL模式VERIFY_CA和VERIFY_IDENTITY是比REQUIRED更好的选择因为它们有助于防止中间人攻击。

若要实现其中一个设置必须首先确保服务器的CA证书对环境中使用它的所有客户端都可靠可用否则将导致可用性问题。

当您需要确定事件时间或位置以在执行事件之前选择部分日志内容时查看日志内容非常有用。

要查看日志中的事件请将mysqlbinlog输出发送到一个分页程序中

mysqlbinlog

如果在MySQL服务器上有多个二进制日志要应用请使用单个连接来应用要处理的所有二进制日志文件的内容。

以下是一种方法

mysqlbinlog

例如假设在2020年3月11日20:06:00左右执行了一条SQL语句删除了一个表。

您可以执行时间点恢复将服务器恢复到删除表之前的状态。

以下是实现这一目标的一些示例步骤

恢复在感兴趣的时间点之前创建的最后一个完整备份称为tp在我们的示例中为2020年3月11日20:06:00。

完成后请记下已将服务器还原到的二进制日志位置以便以后使用然后重新启动服务器。

虽然恢复的最后一个二进制日志位置也会在恢复和服务器重启后由InnoDB显示但这不是获取恢复的结束日志位置的可靠方法因为在显示位置反映的时间之后可能会发生DDL事件和非InnoDB更改。

您的备份和恢复工具应该为您的恢复提供最后一个二进制日志位置例如如果您正在使用mysqlbinlog执行任务请检查二进制日志回放的停止位置如果您使用的是MySQL

Enterprise

查找与要恢复数据库的时间点对应的精确二进制日志事件位置。

在我们的例子中假设我们知道表删除发生的大致时间tp我们可以通过使用mysqlbinlog实用程序检查该时间前后的日志内容来找到日志位置。

使用--start-datetime和--stop-datetime选项指定tp附近的短时间段然后在输出中查找事件。

例如

mysqlbinlog

session.original_server_version80019*//*!*/;

/*!80014

session.immediate_server_version80019*//*!*/;

SET

session.pseudo_thread_id16/*!*/;

SET

session.sql_mode1168113696/*!*/;

SET

session.auto_increment_increment1,

session.auto_increment_offset1/*!*/;

/*!\C

session.character_set_client255,session.collation_connection255,session.collation_server255/*!*/;

SET

session.collation_databaseDEFAULT/*!*/;

/*!80011

session.default_collation_for_utf8mb4255*//*!*/;

DROP

original_committed_timestamp1583971668462467

immediate_commit_timestamp1583971668462467

original_commit_timestamp1583971668462467

(2020-03-11

immediate_commit_timestamp1583971668462467

(2020-03-11

session.original_commit_timestamp1583971668462467*//*!*/;

/*!80014

session.original_server_version80019*//*!*/;

/*!80014

session.immediate_server_version80019*//*!*/;

SET

session.sql_require_primary_key0*//*!*/;

CREATE

TABLE为“pets”cats语句可以在二进制日志的232行#和355行#之间的段中找到这意味着该语句发生在日志位置232之后并且该日志位于DROP

仅使用

将二进制日志文件中的事件应用于服务器从您在步骤1中找到的日志位置开始假设为155到您在步骤2中找到的位于感兴趣时间点之前的位置结束即232

mysqlbinlog

该命令将所有事务从起始位置恢复到停止位置之前。

由于mysqlbinlog的输出在记录每条SQL语句之前都包含SET

TIMESTAMP语句因此恢复的数据和相关的MySQL日志反映了事务执行的原始时间。

您的数据库现在已经恢复到感兴趣的时间点tp就在表pets.cats被删除之前。

除了已经完成的时间点恢复之外如果您还想在感兴趣的时间点之后重新执行所有语句请再次使用mysqlbinlog将tp之后的所有事件应用到服务器。

我们在步骤2中注意到在我们想要跳过的语句之后日志位于355位置我们可以将其用于--start-position选项以便包含该位置之后的任何语句

mysqlbinlog

您的数据库已还原为二进制日志文件中记录的最新语句但跳过了所选事件。