admin check index 错误,重建索引无效 ERROR 8134 (HY000)

【 TiDB 使用环境】生产
【 TiDB 版本】5.4 k8s环境
【遇到的问题】
10亿级数据表,共4个索引,其中一个三字段的联合索引使用admin check index 报错,在半个多月前未出现(相同tidb版本),本次在做数据库新集群以及数据导出还原迁移后,做索引检查时,提示索引数据与record中数据不等报错,重建一次索引后依然报错,怀疑为系统bug。

【复现路径】
新建一个5.4的tidb集群环境,将原集群数据使用dumpling导出(原集群后来检查也有同样问题),并在当前集群中导入,检查admin check index 失败,删除索引后重建索引,然后admin check index 同样失败,其它三个索引检查均正确。

【问题现象及影响】

执行admin check index member_0501 uk2_orgId_idNumber_idNumType;

报错为:
ERROR 8134 (HY000): col document_type, handle 7775021743, index:types.Datum{k:0x1, decimal:0x0, length:0x0, i:7274496, collation:"", b:[]uint8(nil), x:interface {}(nil)} != record:types.Datum{k:0x1, decimal:0x0, length:0x0, i:111, collation:"", b:[]uint8(nil), x:interface {}(nil)}, compare err:<nil>

通过主键查询结果为:

通过索引查询为:

从上面查询理解索引也是能正常进行查询的,然后对tikv数据进行了一些查看。例如错误中的数字:7274496转换为十六进制为0x6F0000,其中6F,刚好对应document_type字段真实数据为111,给人感觉是内存对齐哪里出错了。

对底层tikv的数据做了些查看:
/tikv-ctl ldb --db=/var/lib/tikv/db --column_family=write scan --hex --from=0x7A748000000000000AFFF05F69 --to=0x7A748000000000000AFFF05F69FF
得出的数据用tablecodec.DecodeRow方法正常解析。

/tikv-ctl ldb --db=/var/lib/tikv/db --column_family=write scan --hex --from=0x7A748000000000000AFFF05F698000000000FF0000050380000000FF0006A961 --to=0x7A748000000000000AFFF05F698000000000FF0000050380000000FF0006A961FF

上面语句然后grep对应主键的二进制信息得到了索引key信息:
748000000000000AFFF05F698000000000FF0000050380000000FF0006A96101343431FF3930303139FF3833FF303631313435FF35FF32000000000000F9FF0380000000000000FF6F00000000000000F8F9FDF5351EA7FFFC

代码解析出来正确:

以上为其中一个错误,多次执行admin check index也会有不同的错误如下:

MySQL [cqgl_prod]> admin check index member uk2_orgId_idNumber_idNumType;
ERROR 8134 (HY000): col document_type, handle 1384773020, index:types.Datum{k:0x1, decimal:0x0, length:0x0, i:111, collation:"", b:[]uint8(nil), x:interface {}(nil)} != record:types.Datum{k:0x1, decimal:0x0, length:0x0, i:476741369967, collation:"", b:[]uint8(nil), x:interface {}(nil)}, compare err:<nil>

其中是record值错误的为:476741369967,16进制为:0x6F0000006F,也与111的真实值有相关关系。

根据以上信息,我自己判断索引和数据的原始信息应该没有损坏或者异常,而且只是针对这个索引出现了admin check index失败情况,怀疑是否为隐藏bug,各位大佬帮助判断一下,谢谢大家!

附件是建表语句以及自己scan的表meta信息看是否有帮助,需要什么信息辅助判断请留言。
建表语句.txt (2.4 KB) table_schema.txt (38.1 KB)

5 个赞

环境情况说明下,是某个项目中分配的私有云环境,且内网带宽2000Mbps,磁盘为云存储,且为机械盘组的raid,并且宿主机资源比较紧张,偶发会网络或磁盘出现卡顿情况,但以上操作为51节期间操作,资源暂时还好。

3 个赞

重建为了单表,导入数据后依然检查失败,内容和上述差不多,第一次重建索引也报错。昨天晚上再次重建了一次索引,今天上午检查通过没有报错了,准备再检查次,看是否会复现。

3 个赞

感谢反馈,后续信息方便的话也发一下吧,我们跟踪一下

1 个赞

好的,现在我们有个member表没有建分区了,昨天再次重建索引后发现上午检查通过,今天中午会再检查一次确认是好了还是偶发能够通过。
另外有个member_0501保留了现场,就是首贴内容,有什么内容需要了解的可以发下我这边操作上传。

3 个赞

可以用 SQL 再查下报错 handle 的数据和索引:
select document_type from member_0501 where _tidb_rowid=7775021743;
select document_type from member_0501 use index(uk2_orgId_idNumber_idNumType) where _tidb_rowid=7775021743;

3 个赞

3 个赞

执行删除索引看看行不行

1 个赞

这个组合唯一索引,已经删除并重建过了

2 个赞

对member表(没有分区表这个表,之前检查通过了)重新执行了下admin check index,又报错了,感觉有点随机。


2 个赞


记录如下,5月1号,我们先成功删除了索引,再重建了索引。
【备注,截图标红的记录中member表就是上文的 member_0501,后来我们重命名了】

2 个赞

所以这问题最后还是通过重建解决了是吧?

2 个赞

还没解决,重建索引后执行了一次admin check index,成功通过了,昨天晚上又执行了一次,又提示失败了,从数据来看,是一个比较老的数据,并不是这两天创建或修改的,所以当前还是未解决状态

2 个赞

ERROR 8134 应该是这里的报错
https://github.com/pingcap/tidb/blob/v5.4.0/executor/distsql.go#L1189-L1190

可以报错位置处加一些日志,看看是原始数据的问题还是字段抽取时的问题

if cmpRes != 0 {
	logutil.BgLogger().Info("get index raw data:",
		zap.Reflect("idxRow.raw", idxRow.GetRaw(i)),
		zap.Int("idx", idxRow.Idx()),
		zap.Int("i", i),
		zap.Int("Tp", int(tp.Tp)),
		zap.Int("Flag", int(tp.Flag)))
	return ErrDataInConsistentMisMatchIndex.GenWithStackByArgs(col.Name,
		handle, idxRow.GetDatum(i, tp), vals[i], err)
}
2 个赞

10亿数据有些多,不然可以重建一下表,先临时解决了,在看看开发人员定位问题

1 个赞

比较老的数据是通过 MVCC 时间戳判断的吗
curl http://{TiDBIP}:10080/mvcc/key/{db}/{table}/{handle}

2 个赞

暂时抽样看一些查询功能也没出什么问题,还在继续使用,也是尽可能提供信息,看是否遇到隐藏bug,帮助开发人员发现修复。
另外member表就是重建的,老表是member_0501

2 个赞

就是数据表有个update_time字段,是自动填入的,查询出来的数据你看截图是比较老的时间,是这个判断的,不是底层。

1 个赞

好的,我尝试编译下先,之前没整体编译过,可能要花点时间,好了再反馈。

1 个赞

nohup.out (64.6 KB)
精简了一些打印内容,这是执行check报错后的日志摘录,看看是否能发现一些问题。

1 个赞