V6.5.3 BR备份、PITR恢复无主键、唯一索引的NONCLUSTERED表完成后,插入数据触发ERROR 1062 (23000): Duplicate entry 'xxx' for key 'xxx.PRIMARY'

Bug 反馈
清晰准确地描述您发现的问题,提供任何可能复现问题的步骤有助于研发同学及时处理问题
【 TiDB 版本】V6.5.3
【 Bug 的影响】新插入数据报错mysql> insert into aaa values(9000,now());
ERROR 1062 (23000): Duplicate entry ‘30001’ for key ‘aaa.PRIMARY’

【可能的问题复现步骤】
BR备份恢复无主键、唯一索引的NONCLUSTERED表,隐藏主键_tidb_rowid设置不正确导致新数据插入报错。
1、原表数据
mysql> show create table aaa;
±------±-------------+
| Table | Create Table |
±------±--------------+
| aaa | CREATE TABLE aaa (
id int(11) DEFAULT NULL,
name varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
±------±---------------+
1 row in set (0.18 sec)

mysql> select *,_tidb_rowid from aaa;
±-----±--------------------±------------+
| id | name | _tidb_rowid |
±-----±--------------------±------------+
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
| 4 | 4 | 30001 |
| 5 | 5 | 30002 |
| 6 | 2024-03-18 11:07:54 | 30003 |
| 7 | 2024-03-18 11:08:05 | 30004 |
| 88 | 2024-03-18 11:11:58 | 30005 |
| 89 | 2024-03-18 11:12:03 | 30006 |
| 890 | 2024-03-18 11:17:20 | 30007 |
| 891 | 2024-03-18 11:17:24 | 30008 |
| 892 | 2024-03-18 11:17:27 | 30009 |
| 892 | 2024-03-18 11:22:28 | 30010 |
±-----±--------------------±------------+
13 rows in set (0.01 sec)

mysql> mysql> show table aaa next_row_id\G
*************************** 1. row ***************************
DB_NAME: test
TABLE_NAME: aaa
COLUMN_NAME: _tidb_rowid
NEXT_GLOBAL_ROW_ID: 60001
ID_TYPE: _TIDB_ROWID
1 row in set (0.00 sec)
2、进行BR:V6.5.3全量备份
3、进行BR恢复
4、基于BR库或者表的恢复后数据查询
mysql> select *,_tidb_rowid from aaa;
±-----±--------------------±------------+
| id | name | _tidb_rowid |
±-----±--------------------±------------+
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 1 | 3 |
| 4 | 4 | 30001 |
| 5 | 5 | 30002 |
| 6 | 2024-03-18 11:07:54 | 30003 |
| 7 | 2024-03-18 11:08:05 | 30004 |
| 88 | 2024-03-18 11:11:58 | 30005 |
| 89 | 2024-03-18 11:12:03 | 30006 |
| 890 | 2024-03-18 11:17:20 | 30007 |
| 891 | 2024-03-18 11:17:24 | 30008 |
| 892 | 2024-03-18 11:17:27 | 30009 |
| 892 | 2024-03-18 11:22:28 | 30010 |
±-----±--------------------±------------+
13 rows in set (0.00 sec)

mysql> mysql> show table aaa next_row_id\G
*************************** 1. row ***************************
DB_NAME: test
TABLE_NAME: aaa
COLUMN_NAME: _tidb_rowid
NEXT_GLOBAL_ROW_ID: 30001
ID_TYPE: _TIDB_ROWID
1 row in set (0.00 sec)

【看到的非预期行为】



_tidb_rowid大于原表最大值之后再次插入成功;

【期望看到的行为】
BR备份恢复后数据插入正常_tidb_rowid推进正常

【相关组件及具体版本】
TIDB:V6.5.3
BR:V6.5.3

【其他背景信息或者截图】


测试BR:V6.5.8 恢复后结果一样
如集群拓扑,系统和内核版本,应用 app 信息等;如果问题跟 SQL 有关,请提供 SQL 语句和相关表的 Schema 信息;如果节点日志存在关键报错,请提供相关节点的日志内容或文件;如果一些业务敏感信息不便提供,请留下联系方式,我们与您私下沟通。

mark 一下

有时间我测试一下,应该不至于这样吧

br还有这个问题,我试下

推测触发条件和我原来的表的隐藏主键跳跃了有关,具体是看br备份恢复后_tidb_rowid的起始值设置逻辑

可以试试相同操作在比较新版本的表现,还有 br 是否正确退出了?

请问这个是恢复到原集群还是恢复到新的集群中呢?这里具体的操作是先 br backup full全量备份,然后使用 br restore db 或者 br restore table 么, 3 步骤的恢复是做的啥呢

2、进行BR:V6.5.3全量备份
3、进行BR恢复
4、基于BR库或者表的恢复后数据查询

恢复到原集群,中间使用了br restore point,推测是br restore point时间点覆盖了导致,现在复现不了