Error when using reparo to restore binlog log files on CentOS 7.6 with TiDB v6.6.0

Translated
1

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

Original topic: centos7.6 tidbv6.6.0 使用reparo恢复binlog日志文件报错

| username: TiDBer_BwNZ5U9X

[TiDB Usage Environment] centos7.6
[TiDB Version] v6.6.0
[Reproduction Path] ./reparo --config ./rst.toml
[Encountered Issue: Problem Phenomenon and Impact]
rst.toml file content

data-dir = “/share/mountpoint/s_tidb/tidb-test/CA5BF5BE51144B23BC9226BD38D6D1CB/”
log-level = “debug”
start-tso = 0
stop-tso = 0
dest-type = “mysql”
txn-batch = 20
worker-count = 16
safe-mode = true
[dest-db]
host = “10.10.217.3”
port = 4000
user = “root”
password = “123456”

Using binlog file for recovery
Recovery failed, error reported [“close reparo failed”] [error=“Error 1062: Duplicate entry ‘6’ for key ‘info.PRIMARY’”]

The table does not have a primary key, it only has one field, and I can’t figure out why this error occurs. The key issue is that it is not always reproducible, which makes it very difficult.
[Resource Configuration]
[Attachment: Screenshot/Log/Monitoring]

CE6F2429-B11F-4ca6-8ED7-EABDCF490BB1
CE6F2429-B11F-4ca6-8ED7-EABDCF490BB11380×662 797 KB

2
| username: xfworld | Original post link

Can you share the table structure?

3
| username: TiDBer_BwNZ5U9X | Original post link

The image you provided is not accessible. Please provide the text content for translation.

4
| username: TiDBer_BwNZ5U9X | Original post link

The old version 5.3.4 of TiDB does not have this issue.
If there is a primary key in the table, there will be no problem.
For tables without a primary key, the issue appears in versions 6 and above.

5
| username: xfworld | Original post link

The compatibility of binlog in version 5.X is not very good, and it’s even worse in version 6.X. It is recommended to use ticdc as a replacement.

If it is a SQL script, you need to refer to the relevant structure.

6
| username: TiDBer_BwNZ5U9X | Original post link

I tried multiple times and summarized the issue: restoring binlog for tables without primary keys will result in errors. I added a retry mechanism in my code to address this, but the restored data was disordered. Later, I changed the “downstream synchronization concurrency” setting to 1 in the restore configuration, and the data was finally correct.

7
| username: xfworld | Original post link

If there is no primary key, a hidden primary key will be generated by default…

This is described in the official documentation.

8
| username: TiDBer_BwNZ5U9X | Original post link

Forget it, I won’t use binlog after all. Thanks!

9
| username: system | Original post link

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