TiCDC 实现 TiDB 备份方案

作者： david521 原文来源：https://tidb.net/blog/f1f18adf

背景：

目前 Tidb 备份方案有很多，比如 BR 和 dumpling/lightning 全量备份，但是从 4.0.6 之后 TICDC 的出现，让我对备份产生了新的认识，可以实现在线热备份，还可以对备份集群进行查询或者数据分析等场景非常多，于是想尝试一下

一 、 单向同步

B 集群可以作为 A 集群的热备份，另一个也可以分摊一定的读流量

二 、 双向同步

双向同步可以用来针对两个不同的业务，创建不同的数据库，分别进行对应的库表读写业务分离，彼此互为热备

三 、 多库合一

这种模式主要针对数据汇总场景，上游多个 tidb 集群可以把自己的库表同步到下游 c 中，在 c 中拥有上游 AB 集群的某些库表，在 C 中进行数据分析汇总

四 、 我想的备份恢复方案

我的想法是集群数据量特别大的话，可以跟业务协商只备份某些重要的表到备份集群 B，小集群可以全备，同时设置备份 B 集群的 gc 时间长一点，gc 设置时间变长会有旧版本积累，对应数据量会增大，对这个表进行查询更新会变慢，不过 B 集群没有对应的业务进行读写还好，当真的发生误操作的时候来快速恢复数据，高级权限必须做好限制，当然一般业务是没有 drop/truncate 这些高危命令权限的

五、模拟误删除故障

版本：

Tidb 5.2.1

TICDC 5.2.1

假设出现误删除操作，前提已经创建好了 TICDC，以 truncate table test 为例：

test 有一条数据 2

同时设置备份集群 B 的 GC 时间改为 1h

set global tidb_gc_life_time=‘1h’;

#5.x 建议通过系统变量直接修改，之前版本通过 mysql.tidb 这个表来更新，5.x 也可以

14:25 删除，等待超过 10 分钟，在 15:04 再去尝试恢复 test 表

在 A 集群执行 ：

admin show ddl jobs;

# 发现删除表的时间一直在实时更新…懵…感觉是集群应用来 ticdc 之后的 bug，希望官方能测试下，不过现实中对具体误操作时间也是很难把握准，所以我们可以按照某个时间点依次尝试即可

A 集群 GC 设置的时间是默认 10 分钟，15 点的时候恢复早就过了 GC 时间所以产生如下提示

B 集群执行：

此时我们就可以通过 dumping 或者 flahsback table 来恢复数据，具体恢复步骤可以参考海军这篇备份恢复文章还是比较全面的

TiDB 备份恢复 备份 & 数据迁移

读取历史数据 TiDB 使用 MVCC 管理版本，当更新 / 删除数据时，不会做真正的数据删除，只会添加一个新版本数据，所以可以保留历史数据。历史数据不会全部保留，超过一定时间的历史数据会被彻底删除，以减小空间占用以及避免历史版本过多引入的性能开销。 TiDB 使用周期性运行的 GC（Garbage Collection，垃圾回收）来进行清理，关于 GC 的详细介绍参见 TiDB 垃圾回收 (GC)…

注意！！！

以上方案目前是测试环境尝试的案例，生产还未上线，希望有实现的或者感觉有啥问题的多多交流下，非常感谢～