Error when restoring data for 2 tables with BR: panic: index not found in origin table, please check the restore table has the same index info with origin table

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

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

| username: vcdog

[TiDB Usage Environment] Production Environment
[TiDB Version] v5.4.0
[Reproduction Path]
[Encountered Problem: Problem Phenomenon and Impact] When using br to restore a table to the target database table, if there is no index on the source table and the target table has an index added before using br to import, the above error will be reported.

br import error:

# 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

When using br to restore, is there a parameter similar to lightning that allows ignoring table creation if the table already exists and only importing data?
[Resource Configuration]
[Attachment: Screenshot/Log/Monitoring]

2
| username: xfworld | Original post link

The index will also have corresponding region data, and the metadata must match to perform the backfill, otherwise, an error will occur.

It is estimated to be very difficult to support… Even in version 6.5.X, this scenario will still exist. The metadata must be consistent, even if the column order is inconsistent, it can still work.

3
| username: Kongdom | Original post link

BR is a physical backup, so it should not be supported.

4
| username: 裤衩儿飞上天 | Original post link

The basic principle of physical backup is to copy OS-level data files.

5
| username: 考试没答案 | Original post link

Have you set up NFS or other shared storage???

6
| username: 考试没答案 | Original post link

Please send your backup command and check if it was successful. Share a desensitized screenshot for us to see.

7
| username: vcdog | Original post link

Indeed, the metadata was inconsistent on both sides. Previously, the table structure was created in advance and indexes were added, leading to metadata inconsistency. Re-backing up with BR and then importing resolved the issue.

8
| username: 考试没答案 | Original post link

In other words, TiDB still has consistency issues. Traditional relational databases have never had problems with data and index inconsistencies.

Solution: Previously, there were several cases with similar metadata and index issues. They were all resolved by rebuilding.

9
| username: 考试没答案 | Original post link

Who can explain? Why does the issue of data and index inconsistency occur?

10
| username: vcdog | Original post link

There is no issue with TiDB’s consistency. The BR backup tool itself is fine, and the logs exported by BR also indicate a successful backup.

The problem lies in:

  1. When importing into a new replica using BR, the table structure from the primary database was manually created in the target replica, and several indexes were added.
  2. After this operation, when using BR to import, BR found that the table structure it was going to import was missing several indexes compared to the manually created table structure.

However, initially, the import can proceed normally, but when the progress bar reaches around 70%, it reports the above-mentioned index inconsistency error.

11
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.