Admin CleanUp Index清除索引不干净BUG

Bug 反馈
清晰准确地描述您发现的问题,提供任何可能复现问题的步骤有助于研发同学及时处理问题
【 Bug 的影响】
check某个表时报错,索引数据和真实数据数量不一致,索引多,不管是使用cleanup还是recover 都不能够修复

使用check index 发现索引数多于实际数据:
image

使用cleanup index,并未删除多于index:
image

尝试再用recover index也无济于事:
image

还是index多,无法使用:
image

我的tidb集群是4.0.11版本,我看到之前2.0.6就已经修复了这个bug,但是目前来看还是存在这个问题,
请帮忙排查和给出修复思路吧:

表的schema,有两个索引,都是这个问题:
CREATE TABLE fact_3718 (
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(1000) DEFAULT NULL,
keyword_frequency varchar(500) 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),
KEY doc_id (doc_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

2 个赞

什么时候发现索引不一致的,最开始部署就是 4.0.11 版本么,没有做过版本升级

对的,部署的就是4.0.11,是使用tispark写入(有primary key 和doc_id的一个普通索引),写入过程中有doc_id重复,然后使用了replace来替换,这样的就会有索引不一致问题

1 个赞

目前已经使用索引重建、包括重建主键索引,进行了修复,但是这也是个问题,不可能每次出问题了手动修复吧

之前就出现过几次吗,这个问题能比较容易复现出来么

出现过很多次,但是大部分的表都是cleanup后就好了,有两次是需要重建才能好,复现的话,因为不是我再写入,是别的部门的人再写入,写完后查询就有这个问题了,我了解了下他们的写入逻辑就是上面说的那样,有重复数据,并且开启了replace

了解了,可以关注之前这个帖子 查询报错:inconsistent extra index PRIMARY, handle 4975703 not found in table ,研发在跟进排查,有进展了会反馈哈

1 个赞

好的。

v5.1 也遇到了这个问题。cleanup 和 recover都执行过了,但是索引数据还是不对

我们只能是删除索引,再重建,tispark有bug

删除后重建是没问题的是吧?

2 个赞

坐等结果出来

2 个赞

是的,删不干净是tispark写入索引时的bug,删除重建后肯定没啥问题

2 个赞

确定是bug可以提个单子给官方

2 个赞

速度够快

tispark提了好几个了,tispark团队缺人

是提了单子官方还没安排上是吧?这个估计就得等了

2 个赞