br恢复2张表数据时，报错：panic: index not found in origin table, please check the restore table has the same index info with origin table

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.4.0
【复现路径】
【遇到的问题：问题现象及影响】br进行表恢复到目标库表时，源表上没有索引，目标表先添加索引，再使用br导入时，就会报出上面的错误。

br导入报错：

# tiup br restore full     --pd "10.3.x.222:2379"     --filter 'bj_sjzt_db.zhcx*incoming_alldata'     --storage "local:///data/backup/backup_2023-02-17_bj_sjzt_db"     --ratelimit 128     --log-file bj_sjzt_db_2tabs_restore.log
tiup is checking updates for component br ...
Starting component `br`: /root/.tiup/components/br/v5.4.0/br /root/.tiup/components/br/v5.4.0/br restore full --pd 10.3.x.222:2379 --filter bj_sjzt_db.zhcx*incoming_alldata --storage local:///data/backup/backup_2023-02-17_bj_sjzt_db --ratelimit 128 --log-file bj_sjzt_db_2tabs_restore.log

Detail BR log in bj_to_tj_2tabs_restore.log 
Full restore <-------------------------------------------------------------------|...........................> 71.33%
panic: index not found in origin table, please check the restore table has the same index info with origin table

goroutine 14829 [running]:
go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc000a52000, 0xc000fba000, 0x5, 0x5)
        /nfs/cache/mod/go.uber.org/zap@v1.19.1/zapcore/entry.go:232 +0x532
go.uber.org/zap.(*Logger).Panic(0xc002ede360, 0x3c19f45, 0x69, 0xc000fba000, 0x5, 0x5)
        /nfs/cache/mod/go.uber.org/zap@v1.19.1/logger.go:230 +0x85
github.com/pingcap/log.Panic(0x3c19f45, 0x69, 0xc000fba000, 0x5, 0x5)
        /nfs/cache/mod/github.com/pingcap/log@v0.0.0-20210906054005-afc726e70354/global.go:54 +0x10b
github.com/pingcap/tidb/br/pkg/checksum.buildRequest(0xc000b24340, 0x15ce, 0xc00181a5f0, 0x632, 0x6197b12691c0001, 0x4, 0xc0008758f8, 0x127405c, 0x56ed0a0, 0xc0015cf380, ...)
        /home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/br/br/pkg/checksum/executor.go:132 +0x845

br恢复时，有没有可以象lightning那种参数，如果表已经存在，就忽略不创建表，只导入数据?
【资源配置】
【附件：截图/日志/监控】

2

index 也会有相应的region 数据，元数据必须匹配才能进行回填，不然就报错了

估计很难支持… 即使到了 6.5.X 也会有这个场景，必须元数据一致，即使列顺序不一致都可以

1 个赞
4

BR是物理备份，应该是不支持的。

5

物理备份基本原理是拷贝os级的数据文件

6

nfs 或者其他共享存储搭建了没？？？

7

您把您的备份命令发下，并看看成功了没。 脱敏截图发下看看

8

确实是两边元数据不一致，之前，是采用提前创建表结构，并添加索引，导致元数据不一致。重新使用br备份一份，再导入问题解决。

9

也就是说：tidb的一致性问题上还是有问题的。 传统的 关系型数据库从来没出现过数据和索引不一致的问题。
解决办法：以前有几个单子都是类似 元数据和索引的问题。 都是重建解决的。

10

谁能介绍下？ 数据和索引不一致问题，为什么会导致呢 ？？

11

tidb的一致性问题没有问题。br备份工具，本身是没有问题的。br导出的日志里，也提示备份成功。

问题出在：
1.在br导入新的从库时，提前在目标从库中，手工创建了主库那边的表结构，以及新增了几个索引。
2.这样操作后，在使用br导入时，br发现它要导入的表结构和手工创建的表结构，少了几个索引。

但是，刚开始是可以正常导入，只是导入进度条到70%左右，会报上面那个索引不一致的错误提示。

12

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