BR在a集群备份成功,用在b集群还原失败

【 TiDB 使用环境】生产环境
【 TiDB 版本】6.1.2
【复现路径】做过哪些操作出现的问题,a集群是5.3.1升级到6.1.2的版本,br工具也做了升级,另外我们新建了一套集群b
【遇到的问题:问题现象及影响】经过操作发现,我们历史5.3.1的br备份,在b集群6.1.2可以还原成功,但是数据查询无结果。把现有的集群a数据做br备份,在b集群还原失败。现在寻求一个可靠的数据同步组件方案,把a集群数据同步b集群后,业务迁移到b集群。
【资源配置】
【附件:截图/日志/监控】两套集群都是6.1.2版本的br,可以换别的版本进行操作吗?具体问题如何排查?

(base) [root@tidb0003 cluster]# ./br backup table \

–db spider --table aba_quarterly \

–pd “172.16.16.13:2379” \

-s “local:///home/br-backup/table/quarterly/20221221” \

–log-file backupfull.log

Detail BR log in backupfull.log

Table Backup <--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%

Checksum <------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%

[2022/12/22 04:45:15.860 +08:00] [INFO] [collector.go:69] [“Table Backup success summary”] [total-ranges=801] [ranges-succeed=801] [ranges-failed=0] [backup-checksum=1m10.426031647s] [backup-fast-checksum=578.474µs] [backup-total-ranges=8] [backup-total-regions=557] [total-take=6m40.065563235s] [Size=15248693413] [BackupTS=438214358710616065] [total-kv=269627120] [total-kv-size=41.97GB] [average-speed=104.9MB/s] [backup-data-size(after-compressed)=15.25GB]

(base) [root@tidb0003 cluster]#

– 还原失败

[tidb@tiup-new tools]$ ./br restore table \

–db spider --table aba_quarterly \

–pd “172.16.16.67:2379” \

-s “local:///home/br-backup/table/quarterly/20221221” \

–log-file backupfull.log \

–check-requirements=false

Detail BR log in backupfull.log

[2022/12/22 04:49:49.665 +08:00] [INFO] [collector.go:69] [“Table Restore failed summary”] [total-ranges=0] [ranges-succeed=0] [ranges-failed=0]

Error: the config ‘new_collations_enabled_on_first_bootstrap’ not match, upstream:False, downstream: True: [BR:Common:ErrUnknown]internal error

[tidb@tiup-new tools]$

看着两边的这个初始化参数不一致呢?这个影响的是库表字符集,可能新集群没开启这个参数导致不支持。

另外如果数据量不大可以考虑dumpling和lightling备份和恢复。 br是物理备份,dumpling是逻辑备份。

–check-requirements=false 我们在后面加了这个,这个就是为了解决这个 true 和false 的问题,你说的这个字符集,如何查看数据库用的是什么字符集?因为我们用navicat查看的字符集是:utf8mb4,排序规则是utf8mb4_bin,两边都是一样的。

我的理解,你得先把上下游这个参数设置一致,然后再跳过这个配置检查,才能正常恢复。

先看看上下游该配置项的值是否相同

梳理一下,你的a集群是从5.3.1升级到了6.1.2,b集群是新建的6.1.2

参数new_collations_enabled_on_first_bootstrap用于控制tidb是否支持新的排序规则,比如utf8mb4_general_ci这种,在6.0之前默认是false,在6.0之后默认是true,并且只能在部署集群时设置。如果你部署ab的时候都没有手动改过,那么就导致你的a集群和b集群参数值不一致的原因。

BR属于物理备份还原,必须要求两个集群的new_collations_enabled_on_first_bootstrap参数一致,和你数据库使用什么字符集排序规则无关,参考BR文档使用限制说明:

结论就是:a集群的备份数据无法在b集群恢复,推荐做法,从a集群用dumpling导出,b集群用lightning导入即可。

我有一套集群,是从5.4.1升级到6.1.2的,为啥 new_collations_enabled_on_first_bootstrap 值也是ture了,升级时没有动这个参数,6.0之前应该是false才对啊。

TiDB root@10.18.13.224:test>
TiDB root@10.18.13.224:test> select version();
+--------------------+
| version()          |
+--------------------+
| 5.7.25-TiDB-v6.1.2 |
+--------------------+
1 row in set
Time: 0.017s
TiDB root@10.18.13.224:test> show config where name like '%new_coll%'
+------+-------------------+-------------------------------------------+-------+
| Type | Instance          | Name                                      | Value |
+------+-------------------+-------------------------------------------+-------+
| tidb | 10.18.13.227:4000 | new_collations_enabled_on_first_bootstrap | true  |
| tidb | 10.18.13.226:4000 | new_collations_enabled_on_first_bootstrap | true  |
| tidb | 10.18.13.225:4000 | new_collations_enabled_on_first_bootstrap | true  |
+------+-------------------+-------------------------------------------+-------+
3 rows in set
Time: 0.061s
TiDB root@10.18.13.224:test>
1 个赞

br工具的版本建议保持一致导入导出,如果设备存储空间足够,也可以使用dumpling和lightling备份和恢复。
tidb v6.1.2用6.1.2版本,tidb v5.3.1用 5.3.1版本的工具

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