TiCDC 实现 TiDB 备份方案

背景:

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

单向同步


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

双向同步


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

多库合一

image
这种模式主要针对数据汇总场景,上游多个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
image
同时设置备份集群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,希望官方能测试下,不过现实中对具体误操作时间也是很难把握准,所以我们可以按照某个时间点依次尝试即可
image

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


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

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


双向同步没显示

我帮你在文章中修改下吧~

感谢您