2019-06-12 黄子程
黄子程
黄子程，网易游戏资深运维工程师，曾参与多款网易代理游戏产品的运营维护工作，后逐渐转向数据库管理维护领域。目前主要工作方向为网易游戏 Relational DBaaS 的后台功能开发和数据库管理维护，在 MySQL 性能调优、故障诊断等方面有丰富的实战经验，爱好学习开发和数据库内核技术知识，致力于成为一名了解业务、熟悉开发的 DBA。
Outline
简单介绍：在 mysql 中 binlog 的功能，flashback 介绍，在 MySQL 业界现有的 flashback 的几种实现。
着重讲解： flashback 的代码实现细节
延伸介绍：对比一下其他 DB 如 MariaDB、Oracle、TiDB 等的数据回滚
延伸思考：flashback 真的 flash 吗？回滚需要注意些什么？
一、简介：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 又是什么鬼？
Whenever the master's database is modified, the change is written to a file, the so-called binary log, or binlog. This is done by the client thread that executed the query that modified the database.
binlog 是 MySQL sever 层维护的一种二进制日志，其主要是用来记录对 MySQL 数据更新或潜在发生更新的 SQL 语句，并以「事务」的形式保存在磁盘中。可以简单将 binlog 理解成为记录数据变更的日志。
有了解 MySQL 或者阅读过 MySQL 数据同步机制介绍的童鞋应该对上面这张数据同步的经典图例不陌生，Binlog 的其中一个重要作用就是用于主从间的数据同步。此外，由于 Binlog 记录的是数据的变更，因此 Binlog 在很多场景中也被用于数据恢复。我们今天谈论的主角 Flashback 也正是基于此。
Flashback 按字面理解是闪回，即将数据回滚到某个时刻的「状态」，市面上现有的 MySQL flashback 工具，均是基于 binlog 这种数据修改日志 ，对数据再次进行与原有的修改相反的操作，从而实现将数据回滚到某个时刻的「状态」。
Note: 当前的 flashback 实现上仅考虑针对 DML 的回滚，针对 drop table/database 等 DDL 暂无法实现（思考为什么？下面详述 binlog 格式会给出相关答案）。
下面给一个简单的 flashback 实现图形举例：
如上图，假设一个学生表有如下操作，在 10:01 分只有 Tony 和 Lucy 两个学生，在 10:05 分新增 Lee 学生，在 10:10 该 Lee 学生年龄被 update 为 33 岁，在 10:15 分从表中删除该 lee 学生。
假设 10:15 分之后没有任何其他数据变更操作，业务在 10:16 发现该删除是误操作，希望将表数据恢复至 10:05 分的状态，那么我们的数据回滚方案即是反转原有的数据操作，并逆序执行：先将该 LEE 学生 INSERT 回表中（此时该学生年龄为 33 岁），再执行 update 操作，将该学生年龄从 33 岁变更为 23 岁。完成这两部操作之后，数据即回滚到 10:05 的状态了。
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 进行适配
