TIDB8.5.3社区版的TIFLASH主机总是异常重启

【TiDB 使用环境】生产环境
【TiDB 版本】8.5.3 社区版
【操作系统】 Linux 5.14.0-503.40.1.el9_5.x86_64(Rocky Linux 9.5)
【部署方式】VMWARE虚拟机
【集群数据量】

IP 组件
10.20.17.186 alertmanager
10.20.17.186 grafana
10.20.17.176 pd
10.20.17.177 pd
10.20.17.178 pd
10.20.17.186 prometheus
10.20.17.184 tidb
10.20.17.185 tidb
10.20.17.182 tiflash
10.20.17.183 tiflash
10.20.17.179 tikv
10.20.17.180 tikv
10.20.17.181 tikv

【问题复现路径】未做过什么操作
【遇到的问题:问题现象及影响】
Tiflash节点10.20.17.183 突然出现主机重启,主机重启后,手工启动TIFLASH启动不了,日志tiflash_tikv.log显示
[2025/12/04 05:34:42.409 +08:00] [INFO] [resource_group.rs:151] [“add resource group”] [ru=2147483647] [name=default] [thread_id=1]
[2025/12/04 05:34:42.411 +08:00] [FATAL] [common.rs:188] [“panic_mark_file /data/tidb-data/tiflash-9000/flash/panic_mark_file exists, there must be something wrong with the db. Do not remove the panic_mark_file and force the TiKV node to restart. Please contact TiKV maintainers to investigate the issue. If needed, use scale in and scale out to replace the TiKV node. https://docs.pingcap.com/tidb/stable/scale-tidb-using-tiup”] [thread_id=1]

检查了其他日志
tiflash_stderr.log
tiflash_error.log
tiflash_error.log
dmesg
/var/log/messages
vmware日志
没有明显的错误

且故障时间点前,TIFLASH的IO/CPU/内存使用都不高。

通过TiDB Dashboard 监控看到,TIKV在故障时间点前的Raftstore error很多,

请问TIFLASH节点主机异常重启与什么有关系呢?谢谢各位大神!

这是提示缩容扩容来替换这个节点。

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面

看看你的资源情况,我感觉是因为资源不够的原因,你的部署方式是怎么样的,资源情况都截图一下。

看看日志里面有没有以下报错:

  • out of memory:内存溢出导致崩溃;
  • disk full/no space left:磁盘满导致崩溃;
  • IO error:磁盘 IO 故障(如磁盘损坏、挂载异常)。

原因在于底层存储数据已损坏。日志中的 panic_mark_file 是一个关键信号,它表明 TiFlash 检测到了严重错误并自我保护性地停止了服务,而之前大量的 Raftstore 错误则是导致这次“崩溃”的“罪魁祸首”。

VMWARE虚拟机有没有检查过网络之类的?

谢谢回复!这个已经做了,现在要找原因。

谢谢回复!资源够,我看过磁盘使用,磁盘使用率很多,IO CPU 内存在故障前都是充足的。

谢谢回复!这个看了没有找到这些报错。

谢谢回复!您意思是TIKV的Raftstore 错误则是导致这次“崩溃”的“罪魁祸首”,有官方的链接做依据吗,谢谢

谢谢,看了vmware日志没有异常。网络方面我看流量也不大。

先移除 panic_mark_file 恢复 TiFlash 服务试试看

panic_mark_file 这个删掉会怎么样?

谢谢回复,这个没尝试,因为已经提示要缩容和扩容了,就直接按照提示做,已经恢复了

谢谢回复,已经恢复,现在再找原因。


看看是不是这个 bug TiDB 8.5.4 Release Notes

v8.5.4 已修复

有这些优化:

系统资源不足、系统环境与依赖缺失、配置或数据异常,具体要看下

谢谢回复,我再看看。

谢谢回复,我再对照SQL和系统看看

可先开启 TiDB 慢日志和执行计划采样,用 EXPLAIN ANALYZE`定位慢查询瓶颈;再给热点表加合适索引,拆分大事务,同时扩容 TiFlash 节点分担分析压力。