查询报错:inconsistent extra index PRIMARY, handle 4975703 not found in table

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
4.0.11

【问题描述】
使用jdbc查询时报错:
Get data from fact_2303 error, retry time 1. error: 8021 (HY000): inconsistent extra index PRIMARY, handle 4975703 not found in table

参考了:https://asktug.com/t/topic/2394,和:https://asktug.com/t/topic/34320
执行第一步:admin CHECK TABLE fact_2303 就报错了:
handle 6973217, index:types.Datum{k:0x5, collation:“utf8mb4_bin”, decimal:0x0, length:0x0, i:0, b:[]uint8{0x33, 0x31, 0x37, 0x34, 0x34, 0x38, 0x33, 0x36}, x:interface {}(nil)} != record:


应该是写入的数据量和索引数据量不一致?但为什么会出现这个问题呢

另附建表语句如下:

CREATE TABLE fact_2303 (
id varchar(40) NOT NULL,
doc_id varchar(40) DEFAULT NULL,
account_id varchar(40) DEFAULT NULL,
pub_code varchar(40) DEFAULT NULL,
pub_type varchar(2) DEFAULT NULL,
pub_time datetime DEFAULT NULL,
subject1_id varchar(50) DEFAULT NULL,
subject2_id varchar(50) DEFAULT NULL,
subject3_id varchar(50) DEFAULT NULL,
subject4_id varchar(50) DEFAULT NULL,
subject5_id varchar(50) DEFAULT NULL,
subject6_id varchar(50) DEFAULT NULL,
subject_keyword text DEFAULT NULL,
aspect1_id varchar(50) DEFAULT NULL,
aspect2_id varchar(50) DEFAULT NULL,
aspect3_id varchar(50) DEFAULT NULL,
aspect4_id varchar(50) DEFAULT NULL,
aspect5_id varchar(50) DEFAULT NULL,
aspect6_id varchar(50) DEFAULT NULL,
aspect_keyword text DEFAULT NULL,
subject_sentiment_type_id int(11) DEFAULT NULL,
subject_sentiment_keyword text DEFAULT NULL,
sentiment_type_id int(11) DEFAULT NULL,
unit_content text DEFAULT NULL,
bi_status_id varchar(20) DEFAULT NULL,
bi_attr_id int(11) DEFAULT NULL,
process_start_time datetime DEFAULT NULL,
process_end_time datetime DEFAULT NULL,
reply_cnt int(11) DEFAULT NULL,
view_cnt int(11) DEFAULT NULL,
like_cnt int(11) DEFAULT NULL,
forward_cnt int(11) DEFAULT NULL,
dislike_cnt int(11) DEFAULT NULL,
collect_cnt int(11) DEFAULT NULL,
play_cnt int(11) DEFAULT NULL,
haha_cnt int(11) DEFAULT NULL,
love_cnt int(11) DEFAULT NULL,
wow_cnt int(11) DEFAULT NULL,
angry_cnt int(11) DEFAULT NULL,
sad_cnt int(11) DEFAULT NULL,
care_cnt int(11) DEFAULT NULL,
coin_cnt int(11) DEFAULT NULL,
danmaku_cnt int(11) DEFAULT NULL,
pv int(11) DEFAULT NULL,
keyword varchar(50) DEFAULT NULL,
keyword_frequency varchar(50) DEFAULT NULL,
media_id int(11) DEFAULT NULL,
media_type_id int(11) DEFAULT NULL,
dedup_label varchar(5) DEFAULT NULL,
doc_type varchar(5) DEFAULT NULL,
author_tag varchar(5) DEFAULT NULL,
flag_qc tinyint(1) DEFAULT NULL,
flag_reject tinyint(1) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1、咱们这是生存环境 还是其他环境?
2、咱们集群有发生过故障恢复之类的事情嘛

这是生产环境,没有发生过故障恢复,就是正常的使用tispark批次写入数据,然后这个表有几百万数据,写完查询时就偶尔有问题,然后admin check下就发现这个问题了

数据修复官方提供了下面两个命令:admin cleanup、admin recover。前者适用于 index 数据多于 data 行数据的情况,会将多余的 index 数据删除掉,后者适用于 data 行数据多于 index 行数据的情况,会将缺少的 index 数据填充完整

我现在admin check table 报错:
handle 1516518, index:types.Datum{k:0x5, collation:“utf8mb4_bin”, decimal:0x0, length:0x0, i:0, b:[]uint8{0x33, 0x31, 0x37, 0x35, 0x31, 0x34, 0x34, 0x31}, x:interface {}(nil)} != record:

这个表数据量是:7640462

这个算是索引少于行数是吧

另外还想问下,出现这种问题的原因是什么呢,集群没出现过问题,使用tispark写入的,tispark是保证事务的,为啥会出现这样的问题呢

然后不管是admin RECOVER fact_2303 还是 admin RECOVER table fact_2303都报语法错误,无法执行

admin RECOVER fact_2303

admin RECOVER TABLE fact_2303

都是报错的,语法错误

https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-checksum-table#语法图

我用这个语句就还是报错:admin RECOVER INDEX fact_2303

如果加上index的话,我不知道index叫啥,这个表就一个主键id,我使用了index_id、id、PRIMARY、'PRIMARY’都不行

index少了,修复后,check table没有问题了,后续我们再观察这个表是否还有问题,另外就是原因是为什么呢?我们就是tispark正常写入,别的表都没有问题,也没发生过崩溃之类的,我们需要知道问题原因来防范生产问题,还请帮忙解答

我们排查一下问题

好的谢谢谢谢,我们是tidb v4.0.11,tispark使用的是基于2.3.14打的一个补丁包(临时修复之前生产 table_id重复问题)

其他表没有问题,只该表有这个问题

tispark 批量插入只是 append 数据,还是会 update 数据?

只append,新建表后直接插入,无其他干扰数据

你是怎么修复的?没看懂,主键的时候,需要怎么写?

主键名字默认是primary,关键字,用票号处理了下 primary
image

:ok_hand:

嗨,想问下排查出原因了吗,我们生产又出现这个问题了,虽然使用修复命令可以修复,但是我们必须从源头解决,不能等问题出现后手动修复,有确定性的原因吗,是bug吗

上一个表是tispark写入300w数据有了这个问题,这次是700多w有了这个问题