Br 进行增量备份的恢复

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】: v4.0.4
  • 【问题描述】:Br 进行增量备份的恢复报错 Error: failed to validate checksum

今天在测试BR工具的备份,现我的备份机制选择的是全量备份+增量备份。我先全量备份一个完整数据库,
./br backup db
–pd “192.168.188.104:2379”
–db BrTest
–storage “s3://tidb.backup/20201224/BrTest11?endpoint=http://192.168.188.118:9000
–s3.region “us-east-1”
–send-credentials-to-tikv true
–log-file backuptable.log

然后在一个表中添加几条数据,再进行增量备份,
./br backup db
–pd “192.168.188.104:2379”
–db BrTest
–storage “s3://tidb.backup/20201224/BrTest22?endpoint=http://192.168.188.118:9000
–s3.region “us-east-1”
–send-credentials-to-tikv true
–lastbackupts 421734227041058817
–log-file backuptable1.log

然后又继续添加几条数据,再进行增量备份,
./br backup db
–pd “192.168.188.104:2379”
–db BrTest
–storage “s3://tidb.backup/20201224/BrTest33?endpoint=http://192.168.188.118:9000
–s3.region “us-east-1”
–send-credentials-to-tikv true
–lastbackupts 421711594659774465
–log-file backuptable1.log

然后随机删除了几条数据,现在我想要恢复删除之前的数据,是应该先恢复第一个全量备份数据BrTest11,再依次恢复BrTest22、BrTest33的吧?但是我执行命令:
./br restore db
–pd “192.168.188.104:2379”
–db BrTest
–storage “s3://tidb.backup/20201224/BrTest11?endpoint=http://192.168.188.118:9000
–s3.region “us-east-1”
–send-credentials-to-tikv true
–log-file restorefull.log

就报错Error: failed to validate checksum

这是为什么呢?我恢复BrTest22和BrTest33的数据没有报错,但是数据库实际并没有恢复我删除的数据。

然后我一并把这个库的表删掉,再依次恢复BrTest11、BrTest22、BrTest33的数据,这样数据就完全恢复回来了。

我有个疑问,不能每次恢复都要先把库表删除?
文件是恢复BrTest11数据的报错日志文件,求各路大神帮忙解决,谢谢!
restorefull.log (13.5 KB)

1 个赞

br 目前的实现是直接将备份是的 kv 用当前(最新)的时间戳写到集群里面去。所以对于备份之后的变更(如 insert) 产生的新 kv, br 不会将它们删除。
所以对于新增的数据,如果备份里面有对应的 key, 就会用备份的 kv 覆盖;否则的话,就会不处理,所以直接原地恢复的话,恢复的结果就比较难说了。
不过把相关的 db/table 的数据清理了,这样是 ok 的。

感谢你的回答!
我刚又遇到了一个新的问题想要问一下:
我昨天下午使用BR对数据库做了全量备份,然后刚刚在做增量备份时,出现了报错:

请问GC的tikv_gc_life_time会对BR备份有影响吗?我的tikv_gc_life_time设为12h,但是看了官方文档说


我的TiDB是v4.0.4版本的,为啥会报这个错误呢?

备份打印的日志如下文件,谢谢!backupdb.log (319.6 KB)

你好,是否可以提供下链接,我们修改下。自适应 GC 是在 4.0.8 生效的。

这是官方文档链接:
https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-tool#br-命令行描述

所以我要把GC的时间改长点吗?我是每天做crontab定时备份的,那我GC时间要设24h以上吗?

对的,手动改下 gc 时间,或者是升级到 4.0.8 以后的版本。

如果想要每天一个增量备份,gc必须等于24,这样会造成多版本的问题, 产生大量的慢sql的问题

TiDB v4.0.8 及以上版本已经有自适应 GC 的特性,理论上可以不需要手动调整 GC 时间,可以评估测试下 :

https://docs.pingcap.com/zh/tidb/stable/backup-and-restore-use-cases#备份前的准备工作

不是自适应GC这个问题, 是假如我每天做个全备,GC时间必须等于24. 那样会有很多慢查,而且GC的时候io压力会很大

每天做个全备,为什么会有这样的需求呀 ? 如果你是每天都要做全备,数据量比较大的情况下,即使有自适应 GC,也会线上集群存在一定的影响。

不建议GC调整为24这样操作,我们已经踩过了,对生产影响很大。

如果需要做增量备份,GC的时间应该得设置为24小时,那这样的话,看来是不能使用BR每天做增量备份了?

可以晚上进行吧,我们这边是每天晚上10点调整GC,然后开始备份,早上8点业务开始时还原GC。基本一晚就备份完成了,我们不需要实时备份。

你的意思是,每天做全备份?

我们数据量不大,每天全备

你们是设置过24h,然后发现对生产的影响很大?已经踩过了?

是的,设置过24h,影响了生产。不过,如果硬件足够充裕,不知道能不能避免影响。

:flushed:

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。