非常感谢Pingcap公司组织本次Hackathon活动，本次比赛以"Improve"为主题，将近40只队伍参赛，最终10个作品获奖。在坤坤（李坤）的热心撮合下我们组建了Better战队，小组成员有: 黄潇、吕磊、高海涛和Pingcap同学王相，感谢几位大佬不离不弃带我飞，拿到了最佳贡献奖。比赛过程惊险刺激（差点翻车），比赛快结束的时候才调通代码，强烈建议以后参加Hackathon的同学们一定要抓紧时间，尽早完成作品。
下面介绍下我们的项目:
项目地址Better-PITR
现状痛点
维护过数据库的同学应该都能体会，数据备份对于数据库来说可以说至关重要，尤其是关键业务。目前TiDB原生的备份恢复方案有如下几个痛点:
- 数据量大，不能频繁做全量备份
- 传统TiDB-Binlog需要串行恢复，耗费大量磁盘空间不说，恢复速度还很慢
- Binlog本身是有依赖关系的，任何一个时间点的binlog丢失，都会导致后面的数据无法恢复
-
调大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的快速时间点恢复。
方案介绍
-
根据互联网行业特征和2/8原则，每天真正会被更新的数据只有20%而且是频繁更新。我们也统计了线上万亿级别DML中CUD真实占比为15:20:2，其中update超过了50%。row模式的binlog中我们只记录前镜像和最终镜像，可以得到一份非常轻量的“差异备份”，如图所示:
Binlog merge原则 -
我们将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
-
在此基础上，我们做了些优化:
优化后
备份集的格式与Binlog相同，所以，备份集之间可以根据需要再次合并，形成新的备份集，加速整个恢复流程。
实现方式
-
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工具，将备份集并行回放到下游库。
- DDL的处理
Drainer 输出的 binlog 文件中只包含了各个列的数据，缺乏必要的表结构信息（PK/UK），因此需要获取初始的表结构信息，并且在处理到 DDL binlog 数据时更新表结构信息。DDL 的处理主要实现在 DDLHandle 结构中：
DDL处理
首先连接 PD 获取历史 DDL 信息，通过这些历史 DDL 获取 binlog 处理时的初始表结构信息，然后在处理到 DDL binlog 时更新表结构信息。
由于 DDL 的种类比较多，且语法比较复杂，无法在短时间内完成一个完善的 DDL 处理模块，因此使用 tidb-lite 将 mocktikv 模式的 TiDB 内置到程序中，将 DDL 执行到该 TiDB，再重新获取表结构信息。
方案总结
- 恢复速度快
merge掉了中间状态，且实现了行级并发 - 节约磁盘空间
测试结果表明，我们的binlog压缩率可以达到30%左右 - 完成度高
程序可以流畅的运行，并进行了现场演示 - 表级恢复
由于备份集是按照表存储的，所以可以随时根据需求灵活恢复单表 - 兼容性高
方案设计初期就考虑了组件的兼容性，pitr工具可以兼容大部分的TiDB的生态工具
方案展望
Hackathon比赛时间只有两天，时间紧任务重，我们实现了上面的功能外，还有一些没来得及实现的功能。
-
增量与全量的合并
方案展望
增量备份集，逻辑上是一些insert+update+delete语句。
全量备份集，是由mydumper生成的create schema+insert语句。
我们可以将增量备份中的insert语句前置到Fullbackup中，全量备份集配合Lightning工具急速导入到下游TiKV集群，Lightning恢复速度是逻辑恢复的5-10倍，再加上一份更轻量的增量备份集(update+delete)直接实现PITR功能。 -
DDL预处理
处理一段Binlog期间，为了保证数据一致性，如果遇到DDL理论上要落盘重置程序起点。为了加速恢复速度，我们可以将DDL做一些预处理，比如:
DDL预处理
结语
再次感谢下Pingcap官方组织的这次活动，短短两天让我们学到很多，收货很多，见到非常多优秀的选手和炫酷的作品，我们还有很长的路要走，希望这个项目能继续维护下去，期待明年的Hackathon能见到更多优秀的团队和作品。
