horching
(Horching)
1
为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
- 【TiDB 版本】:v4.0.4
- 【问题描述】:是这样的,我最近想验证一下br对某一个数据库的增量恢复功能,发现恢复的效果不是我想要的,有部分数据是缺失了,不知道是不是我操作有什么问题,麻烦大佬帮忙看看。
我的操作:先使用br对tidb数据进行全量备份—》然后update数据库A一条数据 —》对tidb进行第1次增量备份—》drop数据库A—》使用全量备份数据恢复数据库A—》使用第1次增量备份数据恢复数据库A—》数据库A成功恢复—》再次update数据库A一条数据—》对tidb进行第2次增量备份—》drop数据库A—》使用全量备份数据恢复数据库A—》使用第2次增量备份数据恢复数据库A—》数据库A只恢复了被修改的那一条数据,其他的表以及里面的数据都不见了,恢复过程也没有显示报错
ps:br使用的也是v4.0.4版本的工具包里的
会不会是因为我在第1次增量备份和第2次增量备份之间做了drop数据库A的操作导致的呢?
还是说我增量恢复的姿势不对呢???
请问你的这个场景里面有没有异常报错呢 ?另外可以通过 BR 的 meta.log 确认一下备份的情况是否有 A 表的信息。
horching
(Horching)
3
我看了下第2次增量备份恢复的日志,只有一个疑似报错的信息
你说的meta.log是指备份文件里的 backupmeta 吗?我看了下,里面是有A库和被改动的表的信息的
抱歉,事情有点多,回复慢了。还有这不是我自己的tidb,实在不方便给你们提供更多信息了
因为步骤好像比较多,所以我按照我的理解重新整理一下,麻烦确认一下是否是这个步骤
- 使用 BR 对 TiDB 数据进行全量备份,all_backup1
- 更新数据库 A 的一条记录 update1
- 使用 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份,inc_backup1
- drop database A
- 使用 all_backup1 恢复到原数据库
- 使用 inc_backup1 恢复
- 数据库 A 成功恢复,A 表中的数据是更新一条记录后的数据 update1
- 再次更新库 A 的一条记录 update2
- 使用 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份,inc_backup2
- drop database A
- 使用 all_backup1 恢复到原数据库
- 使用 inc_backup2 恢复
- 查看恢复结果只有 update2 的更新结果,其他数据都丢失
另外需要确认一下几个点:
- 恢复的时候是直接在原集群恢复的么,目前 BR 恢复数据的话,建议是在新的空集群上进行恢复数据
- 第二次的增量备份如果是以 all_backup1 的 LAST_BACKUP_TS_1 进行增量备份的话,这一部分会有些问题,因为在进行第二次增量备份之前,是通过第一次全量以及第一次增量恢复的集群,恢复过程中虽然数据是恢复的,但是位置点之类的可能被覆盖掉了,所以第二次增量备份可能存在问题。正常的话,建议在第一次全量以及第一次增量恢复集群后,重新进行一次全量备份。
horching
(Horching)
7
您好,感谢回复
列出的13个步骤都是准确的,我就是这样操作的
然后
1、恢复的时候是直接在原集群恢复的。一般来说,是tidb上某个库的数据丢失才会有恢复的需要(其他库不需要作改动),此时重新搭一个新的tidb集群不大现实,而且迁移到新集群也是需要巨大成本的
2、关于位置点之类的可能被覆盖掉这个问题,后面会不会安排修复呢?
这个位点覆盖掉,应该是因为 drop database A 导致这个位点发生了变化,目前 BR 恢复还是在空集群上面进行恢复比较成熟,我们会反馈这个问题,看看能不能支持在线的 BR 恢复。另外建议这类在线恢复场景,建议使用 Dumpling 和 Lightning 的逻辑备份方式,这个方式目前更适合在线恢复场景,同时对其他业务影响较低。
system
(system)
关闭
11
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。