TiDB 7.1.6 升级 8.5.8 后，TiFlash 查询间歇性报 Unknown index file %2D1.idx

🪐 TiDB 技术问题 TiFlash
,
1

【环境】
生产环境，TiUP 部署，TiDB/TiFlash v8.5.8，两个 TiFlash 节点均为 Up。

【问题】
同一 SQL 在 7.1.6 上使用 READ_FROM_STORAGE(TIFLASH[t1]) 可以正常执行（不加 hint 也时而失败），升级到 8.5.8 后时而成功、时而失败。

【报错】
ERROR 1105 (HY000): other error for mpp stream:
Code: 49, DB::Exception:
Check info_iter != dmfile_meta->merged_sub_file_infos.end() failed:
Unknown index file,
dmfile_path=/data/t_/stable
index_fname=%2D1.idx

调用栈：SegmentReader.cpp:92 → MinMaxIndexLoader → DMFilePackFilter.cpp:278。

【已排查】

  • meta 文件均能搜索到 %2D1.idx 字符串，未发现 v*.meta。
  • 抽取一个 DMFile，用同版本 dttool 离线检查，索引映射存在且 MinMax 可读。
  • 尚未定位实际失败的 DMFile，不能确认是文件损坏还是运行时问题。
  • 副本数为 2，AVAILABLE=1，报错表 PROGRESS=0.68，tiflash_replica_read=all_replicas。

【求助】
这是 8.5.8 已知 Bug 吗？如何定位具体失败的 DMFile，有没有修复补丁或可靠的处理方式？

2 个赞
2

看着像是升级后索引文件加载的兼容性问题，不是数据损坏。%2D1.idx 是 URL 编码的 -1.idx，表示空的 MinMax 索引段，7.1 到 8.5 的 DMFile 格式有演进，旧版本生成的空索引段在 8.5 的读取路径上可能触发断言。

2 个赞
3

查下是哪个表，不行就重建这个表的同步

4

这个报错大概率是升级后遗留的 stable 文件格式问题：旧版本（7.1）写入的 DMFile 元数据结构，和新版本（8.5.8）MinMaxIndexLoader 读取时期望的 merged_sub_file_infos 对不上
对这张表手动 compact，重写 stable—— 把老格式 DMFile 用新版本重新写一遍，元数据统一

1 个赞
5

重建恢复了，我是新部署的一套 TiDB8.5.7版本的集群，不是原地升级，不清楚为啥会出现这个问题

2 个赞
6

看你描述，是遇到bug了

1 个赞
7

那个 %2D1.idx 就是 -1，等于 DMFile 的索引没落下来，重新加一遍 TiFlash 副本通常就好了

1 个赞
9

不是已知BUG，等一下不行就重建该表的 TiFlash 副本

1 个赞
10

:thinking: 相关表的 tiflash 副本 set replica 为 0，释放后再加回来问题能解决么？

11

对这表手动compact重写stable，旧7.1的DMFile格式就统一了

12

目前看应该是 bug，为什么？
1、我直接新部署的 tidb8.5.8 集群，2 台 tiflash，开启了 mpp，不是原地升级集群
2、每几天出现一次，每次不同的表，报错count = 0
3、重建过 tilfash 好几次了，没用，过几天照样出现问题

出问题点：

if (unlikely(!intern->count))
    throw Exception("Unexpected internal node which count = 0");
if (isLeaf(intern->children[0]))

怎么解决？
每次都手动重启 2 个 tiflash，好烦，业务方都骂人了。

目前看就是内存数据损坏了，DeltaTree Index 是纯内存结构，重启后从 Delta 层数据重新归并构建，坏掉的树被丢弃，换成了正确的树。磁盘上的 Delta/Stable 数据本身没问题。

1 个赞
13

你这个情况我倾向是 TiFlash 侧的问题，不是磁盘数据坏了：%2D1.idx 就是 -1.idx，是一个空的 MinMax 索引段，正常读取路径不该在这里断言失败。而且你是新部署、每次不同表、重建副本没用、重启就好——重启能恢复说明是内存里的 DeltaTree 索引状态坏了，跟磁盘上的 Delta/Stable 数据没关系。

具体是不是已知 bug 得研发确认，我帮你反馈下。方便的话把 TiFlash 完整报错日志（带 dmfile_path）、information_schema.tiflash_replica 的查询结果、出问题的表结构和能复现的那条 SQL 一起发我，能加快定位。

修复版本出来前先按你说的重启 TiFlash 扛着，抱歉给你和业务添麻烦了。

14

这个对运维同学来说体验有点差啊，我们之前遇到了PG的bug偶尔进入恢复模式只能等pg自行恢复，被一堆人喷