TiDB Hackathon获奖项目 基于Binlog的Fast

非常感谢Pingcap公司组织本次Hackathon活动，本次比赛以"Improve"为主题，将近40只队伍参赛，最终10个作品获奖。在坤坤（李坤）的热心撮合下我们组建了Better战队，小组成员有: 黄潇、吕磊、高海涛和Pingcap同学王相，感谢几位大佬不离不弃带我飞，拿到了最佳贡献奖。比赛过程惊险刺激（差点翻车），比赛快结束的时候才调通代码，强烈建议以后参加Hackathon的同学们一定要抓紧时间，尽早完成作品。
下面介绍下我们的项目:
项目地址Better-PITR

现状痛点

维护过数据库的同学应该都能体会，数据备份对于数据库来说可以说至关重要，尤其是关键业务。目前TiDB原生的备份恢复方案有如下几个痛点:

1. 数据量大，不能频繁做全量备份
2. 传统TiDB-Binlog需要串行恢复，耗费大量磁盘空间不说，恢复速度还很慢
3. Binlog本身是有依赖关系的，任何一个时间点的binlog丢失，都会导致后面的数据无法恢复

4. 调大gc_life_time? 保存时间有限，影响性能，占用集群空间

   
   原生Binlog备份恢复

我们线上使用TiDB已经超过2年，从rc版本到1.0、2.0、2.1以及现在的3.0，我们能感受到TiDB的飞速进步和性能提升，但备份恢复的这些痛点，严重影响了我们TiDB在关键业务的推广。于是，我们选择了这个题目:
基于Binlog的Fast-PITR(Fast point in time recovery)，基于Binlog的快速时间点恢复。

方案介绍

1. 根据互联网行业特征和2/8原则，每天真正会被更新的数据只有20%而且是频繁更新。我们也统计了线上万亿级别DML中CUD真实占比为15:20:2，其中update超过了50%。row模式的binlog中我们只记录前镜像和最终镜像，可以得到一份非常轻量的“差异备份”，如图所示:

   
   Binlog merge原则

2. 我们将Binlog分段，举例说，每天的 binlog 为一个分段，每段按照上面的原则进行merge，这段 binlog 合并后成为一个备份集，备份集是一些独立的文件。由于每一个备份集在merge阶段已经去掉了冲突，所以可以行级并发回放，再加上少量binlog，可以结合full backup快速恢复到目标时间点，完成PITR功能。而且，这种合并的另一个好处是,生成的备份集与Binlog file可以形成互备关系，备份集能够重复生成。

   
   Binlog并行回放
   

   Binlog分段方式可以灵活定义起点&终点:

  -start-datetime string
        recovery from start-datetime, empty string means starting from the beginning of the first file
  -start-tso int
        similar to start-datetime but in pd-server tso format
  -stop-datetime string
        recovery end in stop-datetime, empty string means never end.
  -stop-tso int
        similar to stop-datetime, but in pd-server tso format

3. 在此基础上，我们做了些优化:

   
   优化后
   

   备份集的格式与Binlog相同，所以，备份集之间可以根据需要再次合并，形成新的备份集，加速整个恢复流程。

实现方式

1. Map-Reduce 模型
   由于需要将同一 key（PK/UK）的所有变更合并到一条 Event 中，需要在内存中维护这个 key 所在行的最新合并数据。如果 binlog 中包含大量不同的 key 的变更，则会占用大量的内存。因此设计了 Map-Reduce 模型来对 binlog 数据进行处理：

   
   Binlog合并方式

   • Mapping阶段: 读取Binlog file，通过pitr工具将文件按库名+表名输出，再根据Key hash成不同的小文件存储，这样同一行数据的变更都保存在同一文件下，且方便 Reduce 阶段的处理。

   • Reducing阶段: 并发将小文件按照规则合并，去重，生成备份集文件。

     原 Event 类型	新 Event 类型	合并后的 Event 类型
     INSERT	DELETE	Nil
     INSERT	UPDATE	INSERT
     UPDATE	DELETE	DELETE
     UPDATE	UPDATE	UPDATE
     DELETE	INSERT	UPDATE

   • 配合官方的reparo工具，将备份集并行回放到下游库。

2. DDL的处理
   Drainer 输出的 binlog 文件中只包含了各个列的数据，缺乏必要的表结构信息（PK/UK），因此需要获取初始的表结构信息，并且在处理到 DDL binlog 数据时更新表结构信息。DDL 的处理主要实现在 DDLHandle 结构中：
   DDL处理
   首先连接 PD 获取历史 DDL 信息，通过这些历史 DDL 获取 binlog 处理时的初始表结构信息，然后在处理到 DDL binlog 时更新表结构信息。
   由于 DDL 的种类比较多，且语法比较复杂，无法在短时间内完成一个完善的 DDL 处理模块，因此使用 tidb-lite 将 mocktikv 模式的 TiDB 内置到程序中，将 DDL 执行到该 TiDB，再重新获取表结构信息。

方案总结

1. 恢复速度快
   merge掉了中间状态，且实现了行级并发
2. 节约磁盘空间
   测试结果表明，我们的binlog压缩率可以达到30%左右
3. 完成度高
   程序可以流畅的运行，并进行了现场演示
4. 表级恢复
   由于备份集是按照表存储的，所以可以随时根据需求灵活恢复单表
5. 兼容性高
   方案设计初期就考虑了组件的兼容性，pitr工具可以兼容大部分的TiDB的生态工具

方案展望

Hackathon比赛时间只有两天，时间紧任务重，我们实现了上面的功能外，还有一些没来得及实现的功能。

1. 增量与全量的合并

   
   方案展望
   

   增量备份集，逻辑上是一些insert+update+delete语句。
   全量备份集，是由mydumper生成的create schema+insert语句。
   我们可以将增量备份中的insert语句前置到Fullbackup中，全量备份集配合Lightning工具急速导入到下游TiKV集群，Lightning恢复速度是逻辑恢复的5-10倍，再加上一份更轻量的增量备份集(update+delete)直接实现PITR功能。

2. DDL预处理
   处理一段Binlog期间，为了保证数据一致性，如果遇到DDL理论上要落盘重置程序起点。为了加速恢复速度，我们可以将DDL做一些预处理，比如:

   
   DDL预处理

结语

再次感谢下Pingcap官方组织的这次活动，短短两天让我们学到很多，收货很多，见到非常多优秀的选手和炫酷的作品，我们还有很长的路要走，希望这个项目能继续维护下去，期待明年的Hackathon能见到更多优秀的团队和作品。