一、简介：MySQL binlog 与 flashback

MySQL 的 Flashback 功能最初是由淘宝彭立勋在大概 7 年前并实现的一个很强劲的作品，起初他在 2012 年提交到 Feature Request 到官方 Oracle MySQL 团队的，点击链接可见目前信息仍大都停留在了 2012 年。直至今年稍早时候，又有其他开发者重新提出希望实现这个 feature 的声音。

另一边厢， MariaDB 分支从 10.2.4 版本开始支持 Flashback 功能，起初我们曾尝试使用 MariaDB 版的 mysqlbinlog 来直接实现回滚功能，但无奈经过我们的测试发现由于两个分支的一些实现不同（如 JSON 字段），使用 MariaDB 分支的 mysqlbinlog 工具来解析 MySQL 分支的 binlog 文件会出现错误。

因此为实现这一轻快方便的重要功能，网易游戏数据库团队，在参考前人设计思想（彭立勋，MySQL 下实现闪回的设计思路，美团 MyFlash 闪回工具等等）以及 MariaDB 分支源代码的基础上，自行将这一套 FLASHBACK  Patch 移植到网易游戏自有的 MySQL 代码中去，目前在日常测试和各项应用均表现出色。

本文则着重为各位读者讲解数据库团队在实现 FLASHBACK 上所做的事情，一说就要说彻底，因此我们从最底层的概念科普开始。

1.binlog 是什么， flashback 又是什么？

binlog 是 MySQL sever 层维护的一种二进制日志，其主要是用来记录对 MySQL 数据更新或潜在发生更新的 SQL 语句，并以「事务」的形式保存在磁盘中。可以简单将 binlog 理解成为记录数据变更的日志。

2、当前 MySQL 业界的几种 flashback 实现

①mysqlbinlog 工具配合 sed、awk：先将 binlog 解析成类 SQL 的文本，再使用 sed、awk 把类 SQL 文本转换成真正的 SQL，同时实现语句的翻转。

优点：当 SQL 中字段类型比较简单时，可以快速生成需要的 SQL ，且编程门槛也比较低。

缺点：需要考虑极其复杂的转义等情况，出错概率很大。事实上基本也不会有人这么干的了

②直接使用 MariaDB 的 mysqlbinlog 工具，该工具已支持 flashback

优点：「官方」出品；直接使用

缺点：由于部分功能的实现不同（例如JSON字段的实现），容易出现不兼容原生 MySQL 的 binlog 文件的情况：目前已知的是使用 MariaDB 的 mysqlbinlog 工具对原生 MySQL server 产生的 binlog 中带有 json 字段则会解析失败

③基于业界开源的 binlog 解析库(python-mysql-replication)进行二次开发，直接实现回滚 SQL 的构造，优秀代表是美团点评团队：binlog2sql

优点：使用现成解析库方便就手，信手拈来，上手难度低

缺点：实现上受制于开源库提供的功能，运行效率低，需要使用开源解析库，将 binlog 解析成文本，再操作文本回滚

④自行开发工具对 binlog 文件进行解析与修改：优秀代表同样是美团点评团队在2017年开源的MyFLash

优点：binary 层面的操作，只须关注 binlog 格式与字段类型计算，对于数据库的代码重构不敏感，只要 binlog 版本不变，则不需要大改

缺点：实现上只适配了 v4 版本的 binlog 格式，不能解析 v4 以前的老版本；由于不能复用 binlog 解析代码，需要处理 binlog 中复杂的字段大小关系

⑤给源码打 patch：直接修改源码扩展 mysqlbinlog 工具的功能，增加 Flashback 的选项操作。

优点：复用了server 层中 binlog 解析代码，因此无须关心复杂的字段类型；能够结合使用到 mysqlbinlog 原有的一些过滤选项

缺点：需要对 mysql 的复制代码结构和细节需要有较为清晰深入的理解；改动的代码分布在 MySQL 的各个文件和函数中，MySQL 版本更新有可能需要重新对 patch 进行适配

1、binlog 基础知识详述

具体来说， MySQL 是以事件(event)为维度将数据变更按时间先后线性记录到 binlog 的，但 binlog 里不单单只有数据变更记录，还有其他诸如 描述该 binlog 文件格式的 event、rotate event、gtid event、start event，可以理解成涉及数据同步所发生的一切事情都以事件形式记录到 binlog，换句话说我们使用 binlog 可以在其他服务器上复现与该 binlog 对应的 server同样的数据变更，以达到和该对应 server 一直的数据状态( master-slave复制)，又或者是某个指定的数据状态。目前网易游戏内部 MySQL DBaaS 服务所提供的精准时刻数据恢复功能也正是利用这个特性，先恢复一个全备份数据，再在该备份数据的基础上应用 binlog 到指点的时刻点。

一个完整的 binlog 文件是由一个 format description event 开头，一个 rotate event 结尾，中间由多个其他 event 组合而成，最常见的包括有

①Previous gtid event：用于表示在这个 binlog 文件之前的全局事务号(GTID)列表，可以理解成这个 binlog 文件就不涉及 previous gtid 了

②Gtid log event：用于表示以下数据变更对应的全局事务号(GTID)

③Query_event：用于记录语句，比如 use database 等 statements，以及 drop table/database 等 DDL (Data Definition Language)。无论 binlog_format 设定成什么格式，这种类型的 event 都只记录语句，而不会记录数据镜像，因此 DDL 语句不能用于数据回滚。

④Table map event：用于表示下述数据变更涉及到的表结构是如何定义，在RBR (Row Based Replication)格式的 binlog 中数据变更和数据表结构定义是作为两个事件( event )分开存放的；

⑤Rows_event : 在 RBR 中用于表示行数据的变更事件，里面存放的是一行或多行的数据镜像，包括以下三种类型

Update_Rows_event：更新数据（即 UPDATE 语句），内容包含有更新后的镜像（AI） 和更新前的镜像 （BI）

Write_Rows_event：写入数据（即 INSERT 语句），内容只包含更新后的镜像（AI）

Delete_Rows_event：删除数据（即 DELETE 语句），内容只包含更新前的镜像（BI）

⑥xid event：表示两阶段提交中的最后一步，即 commit

取决于 binlog_format的配置，SQL查询可能有以下记录方式：

①STATEMENT：将 MySQL server 上执行的一个个 更新数据的 SQL statement 以文本的形式写到 binlog 中去，甚至还包括可能没有任何更新的语句也会记录在里面，比如一个删掉 test 表中一行不存在的语句(Rows changes: 0）。在这种格式下，所有的 DML 更新语句会以Query的事件类型(event type) 记录到 binlog 文件中，刚刚已经介绍过 query 类型的事件，是不会记录数据镜像的。因此，在 statement 格式下的 binlog，也无法进行 flashback 操作。

②Row format： 以二进制形式将行变更写到 binlog 中去，每一行的变更可能包括修改前的镜像( Before Image )和修改后的镜像( After Image )，镜像是由一个个字段组成的，可以理解成 BI 存放的就是该行数据变更前的字段的数据，对应的AI 就是该行数据变更后的字段的数据。（这是我们修改的重点）。还要注意有个配置项叫binlog-row-image，用于配置是否记录所有的字段，它默认值是FULL，还有其他可选项minimal：只记录发生变更了的字段以及用于定位数据行的字段；noblob：记录除 BLOB 和 TEXT 类型外的所有字段

③MIX: 即上述两者的混合，由 MySQL server 决定记录方式，此处不过多描述。

综上，我们本篇讨论的 flashback，有一个大前提—— binlog format 设置为 row format，且配置 binlog-row-image 是 FULL。只有在这种情况，MySQL 才会将整个行数据的所有内容存储在 binlog 中，才能实现反转。

使用 mysqlbinlog 对 binlog 文件进行解析的示例图：

2、EVENT 格式

每个 event 都是由 event header 和 event data 组成，以 update_rows_event 举例

4、那么 flashback 的逻辑应该怎么加呢？

按照前面的介绍，最多可能会有三层反转（ update_row )
一、在单个 row_event 里面：对每一行数据进行 BI <—>AI；
二、在单个 row_event 里面：将每一行倒序
三、对于整个 binlog 文件：倒序所有的 row_event

接下来就是深入讲解代码实现逻辑的，为清晰表述思路，会有比较多的简化代码展现，可能会比较深入，需要仔细阅读才能理解。

不过没关系，上图我们给出了整一个 Flashback 的核心实现思想，记住这三个蓝色反转，会对下面的具体代码实现的理解有帮助。

4.1 如何翻转 BI 和 AI？

先重新回顾两个超常见的 event 类型并普及一个基本知识：

①table_map_event：table_map event 包含了所要了表名、库名等元数据信息；

②row_event：只包含真正的数据，表结构定义是没在这里的；

那么思路就变成：
BI <—> AI，反转前后镜像——>涉及到对行数据中 image 的长度计算——>则需要知道对应的 table define——>即需要对应的table map event

那么，这里参考美团的 MyFlash 文档介绍，同样地就可以引入一个概念——最小执行单元，如下图

4.2 最终思路如下

①构造最小执行单元：一个 table_map_event + 若干个 row_event

②反转打印最小执行单元中的单个 row_event：

Write_Rows_event: 因为只含有 AI，无需翻转 AI  和BI，只需改变 event_type_code 为delete_rows_event

Delete_Rows_event: 只含有 BI，无需翻转 AI 和 BI，只需改变event_type_code为write_rows_event

Update_Rows_event: 含有 AI 和 BI，需要反转 AI 和 BI--> 反转过程涉及字段操作，需要知道该行所对应的table_define(td)--> 需要用到其对应的 table_map event

③逆序整个 binlog 的中的所有执行单元队列

4.3 构造最小的执行单元

①使用数组 events_in_stmt 来保存最小执行单元

②在 process_event() 中

每遇到一个 table_map_event，则意味着一个新的 events_in_stmt，则将 events_in_stmt 重置

event 的打印是在 Log_event 类中实现的，因此 mysqlbinlog 只需在是在构造 log_event 的时候，将 log_event 的 is_flashback 标记为 TRUE 即可。

以下是简约代码展示

4.4.1 change_to_flashback() 做了什么？

①遍历行数据

对于 update_rows_event，交换 AI和 BI

将每一行数据存放到临时数组 rows_arr

②将行数据倒序覆盖回去 event

以下是该函数稍作简化后的代码展示

由于涉及到倒序打印，意味着大多数操作都不能马上真正打印，这就涉及到一系列临时保存使用的 buffer 数据结构了。

首先，单个 rows_log_event 的反转打印简要逻辑可以归纳如下

而 Oracle 则是在 12c 推出 Temporal Validity技术，所谓Temporal Validity技术，就是指表记录的可视性将由 PERIOD FOR 指定的时间维度字段的范围而定，只有落在时间字段范围之内的记录，相关 SQL 语句才可看见这些记录，而落在时间字段范围之外的记录，相关 SQL 语句则无法访问这些记录。而记录的时间范围则完全由应用程序来控制

参考介绍：

mariadb 和 oracle 使用的相关语法关键词都是period for，创建示例如下：

这样，我们在查询的时候就可以直接如下的命令一把梭查询到历史的数据，妈妈再也不会担心 DBA 删库跑路啦~

1、Feature Request

2、彭立勋，MySQL下实现闪回的设计思路

3、美团MyFlash闪回工具

4、python-mysql-replication

5、MyFLash