TiDB 与 MySQL 在备份容灾体系的衡量对比
作者： 大数据模型原文来源：https://tidb.net/blog/8788eb77
前文
如果把数据库的工作建设分为三大体系，从前中后的角度来看，笼统一点可以分为开发设计体系【前】、监控优化体系【中】、备份恢复体系【后 】，类似规划设计、运营管理、安全保障的关系，构成数据库整个生命周期的管理。
三大体系中可以看出一个产品的覆盖度广窄 ， 三大体系可以洞悉一个产品的成熟度深浅。三大体系简单简述如下。
开发设计体系考虑的更多是产品技术造型、基准测试报告、最佳施工应用实践、开发者使用标准规范等设计因素。让产品对准业务有的放矢。
监控优化体系考虑更多是流量、延迟、饱和度、关键指标、查询优化等运维因素，让产品健康正常的在生活环境中运行。
备份容灾体系考虑的高可用、业务连续性、不可抵抗力的灾后建设。 必要通过额外的技术手段，保障产品的售后安全
对业务和 DBA 而言，开发设计体系和监控优化体系是 DBA 经常要做的事情，而 备份容灾体系则是一劳永逸的工作，初次进行全面的数据备份策略要花较大的精力。
MySQL 的备份容灾体系成熟度已经很高，针对 MySQL 的备份容灾和 TiDB 的备份容灾做了技术对比。
MySQL 备份体系
MySQL 的备份技术栈有 mysqldumper、mydumper 等逻辑备份工具，也有 xtabackup 等物理备份工具 。
逻辑备份的定义，从数据库的接口层出发，数据库客户端访问数据库服务端，像其它 SQL 语句一样进行正常的解析，最后输出结果为 SQL 语句或者 CSV 文件。
物理备份区别于逻辑文件，直接针对硬盘存在的持久化的物理文件进行备份，因为不需要 SQL 解析，所以处理速度会很快。
mysqldumper 是 MySQL 典型的逻辑备份工具，可以指定某个库、某个表、甚至全库进行备份，当进行备份操作的时候，打开 Gerneral 日志，mysqldumper 会启用全局锁，flush table with read lock 会阻止其它表和数据进行 DDL 和 DML 操作，必须备份完成才会解锁。
mysqldumper 这样的目的是为了备份一致性。数据库工作生产时，一边在大量写入数据，一边需要对数据进行备份，备份的数据要接近生产数据的真实状态，这个就是备份一致性的作用。MySQL 为了做到这一点，提供全局锁flush table with read lock
mydumper 相对于 mysqldumper，它的备份速度要快的多， 因为 mysqldumper 是单线程，而 mydumper 是多线程备份，mydumper 在满足 mysqldumper 的基本功能上，还提供对目标文件进行压缩编码。
mydumper 同样存在不足，它比 mysqldumper 需要占用更多的资源，而且数据进行恢复的时候，同样是在 MySQL 的逻辑层进行 SQL 解析，这个需要花费大量的时间。进行数据恢复的时候 mydumper 比 mysqldumper 占不了多少优势。
xtabackup 是针对 innodb 引擎的备份工具，目前有 2.4 和 8.0 版本，其中 xtabackup2.4 是针对 MySQL5.6 和 MySQL5.7，而 xtabackup8.0 针对的是 MySQL8.0。
xtabackup 的备份技术原理分为三步走。
第一步，物理备份开始，针对 MySQL 最近一次 checkpoint 点进行 redo 日志的日志备份。
第二步 ，针对 IBD 文件【公共表空间文件和独立表空间、undo 文件】、非 IBD 文件【上全局锁】、进行备份。
第三步，当最后一个非 IBD 文件传输完成 ，代表 redo 日志拷贝结束，整个物理备份结束。
xtabackup 的每一步都为了备份一致性
第一步的作用 识别并获取目标数据源，对那些刚刷到硬盘上，没有来得及进入 innodb 引擎的数据进行回放，对一些表空间的脏页尚未递交成功，马上放弃通过 redo 日志进行回放。
第二步的作用 拷贝物理文件，针对非 IBD 文件进行全局锁，防止这个时候有人对非 IBD 进行 DML 和 DDL 操作。在 8.0.27 版本，只允许进行 DDL 操作，不允许进行 DML 操作，进一步细化备份一致性的粒度。
第三步的作用 非 IBD 文件传输完成结束，自行进行解锁，同行监控 REDO 的线程也结束，备份到了最后阶段。
关于增量备份，基于初次全量备份后，xtabackup 通过识别 REDO 日志的 LSN 是否发现变化 ，LSN 的序列号是往前递进的，是否变化一目了然，增量备份只叠加备份后的数据。
关于数据恢复，可以基于全量备份恢复或者增量恢复，或者基于全量备份恢复 + 日志备份恢复的方式。
物理备份上，xtabackup 使用了全局锁技术，REDO 日志监控技术，非 IBD 文件传输等同于 REDO 监控结束等方法保障了全量备份、增量备份，实现了基于时间点的数据恢复，恢复到指定的数据恢复点上。
TiDB 备份体系
TiDB 支持 mysqldumper 和 mydumper 工具， 但是只能逻辑层面对已经持久化的数据进行备份，无法进行一致性备份。
mysqldump 使用--single-transaction进行一致性备份
mydumper 使用备份的时候，提示更是明确
究底根因，目前 TiDB 没有支持全局锁, 只支持 tidb_snapshot，那么 tidb_snapshot 是什么？
这个要说到 TiDB 的内存管理机制，对于写进来的数据，TiDB 把增量数据放到内存，提交成功的数据放在基线数据里面，内存的数据待到适当时机，会冻结合并到基线数据里面。
基线数据是持久化刷新到硬盘里面的数据，每一行数据都会对应一个唯一的时间戳
TiDB 的物理备份工具 BR 的技术原理，就是把已经提交后的物理文件进行时间戳的扫描，把对应的时间点的数据文件信息都集中在一起，分为三步走。
第一步扫描 KEY VALUE，从 TIKV 所在的 Region 读取备份时间点对应的数据。
第二步生成 SST，将数据保存到 SST 文件中，这些文件存储在内存中。
第三步上传 SST，将 SST 文件上传到存储路径。
下面做个小测试，三个时间点2024-04-15 10:18:32, 2024-04-15 10:18:35,2024-04-15 10:22:32, 其中第一个时间连续 备份三次， 期间数据一直在不停的增加中。
在 TiDB 的不断的增加数据的过程中，第 1 个时间点三次备份都是 122M，第 2 个时间点是比第 1 个时间点多 3 秒，备份后数据是 138M，第 3 个时间点备份是 174M，时间越往前，识别的数据就越多。
而且 TiDB 的物理备份的过程中，只从后端爬物理文件，不需要与其它模块协同。而 MySQL 会加上全局锁，防止前端写入数据。两者比较相对而言，MySQL 的备份机制显得谨慎一点，延迟一点，多些安全。
快照的好处在于记住某个时间点的数据总集，可以进行某个时间点的数据恢复，例如误操作把表 truncate 了，由于表以前做过快照，我依然可以通过相同的时间点把数据物理备出来。
除了内置的快照，TiDB 也支持外置的快照 ，通过 LVM 也可以对数据进行备份。
如果使用 LVM 进行备份，注意安装的时候，需要把 TiDB 的数据盘安装在 LVM 的 逻辑卷上面，以下 TiDB 的数据盘安装在 /dev/mapper/centos_server153-tidb--data下面。
备份容灾总结
针对数据库的备份恢复存在多种方法，例如针对数据库的接入层备份恢复、针对数据库的服务层进行备份恢复、针对数据库的物理进行备份恢复。
以 MySQL 为例，支持接入层、服务层、物理层的备份恢复，重视锁处理生产数据的矛盾冲突。
接入层的备份有 mysqldumper 和 mydumper，接入层在数据恢复的时候 ，需要进行昂贵的 SQL 解析，花费大量的时间，虽然 mydumper 备份快，但是数据导入速度也不快。
服务层的备份导出例如 CSV 的规范式文件，再通过 load data 的方式进行导入，如果接入层的恢复是直路导入，那么服务层是旁路导入，旁路导入按照规律快速生成有序组织，避免 SQL 的消耗。
物理层的备份有 Xtrabackup，它可以将把原有的 MySQL 相关物理文件迁移过来，技术层面重视已经持久化的数据和没有持久化的数据，通过 redo 回放数据，释放表空间尚未提交的脏页。经过清洗的数据文件可以马上拿来就用，不需要额外转换。
快照备份，MySQL 支持 LVM 备份
TiDB 同样支持接入层、服务层、物理层的备份恢复，主要通过快照处理生产数据的矛盾冲突。
接入层的备份有 mysqldumper 和 mydumper, 经过 TiDB 的适配二开，由于 TiDB 分布式能力，资源能力潜力较大，间接也提升 mysqldumper 和 mydumper 的使用率
服务层的备份有 Lightning 导入和 Dumpling 导出，Lightning 导入绕过接入层，直接在服务层导入 ，通过转化成 KEV_VALUE 形式，性能较快。
物理层的备份有 BR 工具，直接对 TiKV 进行时间戳扫描，扫描后的文件转换成 sst 文件，如果要恢复数据文件，需要专业工具进行转换。
快照备份，TiDB 支持 LVM 备份
在备份上的策略，MySQL 积极与生产数据协同，达成一致，沟通的方式先上一个全局刷，让它们稍停一会儿。MySQL 甚至有元数据锁，解决 DDL 层面数据结构稳定不变的锁机制。 而备份上 TiDB 的落地则是使用快照确定米已成炊的事实，在锁方面的应用较少，加大了存储成本，但是提升了性能。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/9f7df1cf11ce810ec885f26d2】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论