【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.0
【操作系统】AlamLinux8
【部署方式】机器部署
【遇到的问题：问题现象及影响】
问题背景
现在正在进行集群的迁移，从A集群迁移到B集群，采用的方案是选择时间节点t，从A集群dumpling t之前的数据，然后再挂上A->B的CDC同步任务，同步从t开始的数据
现在CDC任务还是开启状态，同时B上也有写入
问题描述
上述操作完成后现在B集群出现了一个很奇怪的问题 - B集群上的一个表log出现了[kv:1062]Duplicate entry 的主键冲突报错，但是查询了对应表后发现冲突的主键上根本就没有数据
log的表结构如下
CREATE TABLE `log` (
`id` int NOT NULL AUTO_INCREMENT,
`time` timestamp NULL DEFAULT NULL,
`job_type` varchar(128) DEFAULT NULL,
`job_name` varchar(512) DEFAULT NULL,
`msg` longtext DEFAULT NULL,
`suggestion` text DEFAULT NULL,
`err` varchar(512) DEFAULT NULL,
`hostip` varchar(128) DEFAULT NULL,
`cluster` varchar(128) DEFAULT NULL,
`namespace` varchar(128) DEFAULT NULL,
`instance_name` varchar(128) DEFAULT NULL,
`hostname` varchar(128) DEFAULT NULL,
PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
KEY `ins_name` (`instance_name`),
KEY `job_name_IDX` (`job_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=8370002;
而且有一些很奇特的日志，例如下面这一条在调整系统变量的时候都出现了主键冲突报错
[conn.go:1184] ["command dispatched failed"] [conn=3696056984] [session_alias=] [connInfo="id:3696056984, addr:10.254.165.252:56684 status:10, collation:utf8mb4_general_ci, user:root"] [command=Query] [status="inTxn:0, autocommit:1"] [sql=COMMIT] [txn_mode=OPTIMISTIC] [timestamp=459782349450117181] [err="previous statement: SET @@SESSION.`tidb_cdc_write_source`=1: [kv:1062]Duplicate entry '8283808' for key 't_udp_troubleshoot_root_log.PRIMARY'"]
然后所有的报错都来源于同一个TiDB节点，我查询了log表的id分布，其中出现了一个极大的空缺，而且所有的主键冲突的id都在这个空缺里
select id from log where id > 8259000 order by id asc limit 100;
...
8259029
8259030
8287413
8287414
8287415
...
按照类似的问题的一些方法我查询了一些相关变量，看不出什么问题
show table log next_row_id;
DB_NAME|TABLE_NAME |COLUMN_NAME|NEXT_GLOBAL_ROW_ID|ID_TYPE |
-------+---------------------------+-----------+------------------+--------------+
u | log|id | 8370002|_TIDB_ROWID |
u | log|id | 1|AUTO_INCREMENT|
目前的猜测
我个人的感觉是CDC上出现了一些问题导致TiDB节点上的一个范围全部失效了，因为我发现冲突的ID在A集群上的对应表里是存在的，但奇怪的是CDC运行正常，而这个表里却没有相应的数据，但我现在暂时没有进一步排查的线索和方向了