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

goalzz85 · 2022 年5 月 2 日 13:31

【 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)

goalzz85 · 2022 年5 月 2 日 13:34

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

goalzz85 · 2022 年5 月 3 日 01:58

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

spc_monkey · 2022 年5 月 3 日 03:23

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

goalzz85 · 2022 年5 月 3 日 04:12

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

qizheng · 2022 年5 月 5 日 09:08

可以用 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;

方才兄-fighting · 2022 年5 月 5 日 10:08

哈喽沃德 · 2022 年5 月 5 日 11:33

执行删除索引看看行不行

方才兄-fighting · 2022 年5 月 5 日 15:08

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

goalzz85 · 2022 年5 月 5 日 15:14

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

方才兄-fighting · 2022 年5 月 5 日 15:15

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

windyzhousir · 2022 年5 月 6 日 00:10

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

goalzz85 · 2022 年5 月 6 日 02:07

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

qizheng · 2022 年5 月 6 日 12:14

ERROR 8134 应该是这里的报错

github.com

pingcap/tidb/blob/v5.4.0/executor/distsql.go#L1189-L1190


      
          					return ErrDataInConsistentMisMatchIndex.GenWithStackByArgs(col.Name,
          						handle, idxRow.GetDatum(i, tp), vals[i], err)

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

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)
}

张雨齐0720 · 2022 年5 月 6 日 12:17

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

qizheng · 2022 年5 月 7 日 02:07

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

goalzz85 · 2022 年5 月 7 日 02:52

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

goalzz85 · 2022 年5 月 7 日 02:54

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

goalzz85 · 2022 年5 月 7 日 02:57

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

goalzz85 · 2022 年5 月 7 日 07:22

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