TiFlash报错1105-Exception,且查询无法使用Tiflash

Horace · 2026 年5 月 22 日 05:47

【 TiDB 使用环境】测试
【 TiDB 版本】v8.5.5
【复现路径】做过哪些操作出现的问题
在测试快照恢复数据时,单表恢复千万级,万级的数据表没有问题,再遇到亿级表恢复时,我使用了s3协议命令,恢复完表后如果不执行清除TIFlash的命令ALTER TABLE db.schema SET TIFLASH REPLICA 0; 双击打开表就会报错1105-Exception,如果执行清除TiFlash则可以正常打开表,正常查询
【遇到的问题：问题现象及影响】
如何才能让恢复的表可以使用TiFlash呢,是恢复命令的原因还是已有的文件已经损坏呢?

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

TiDBer_odwPM8gO · 2026 年5 月 22 日 07:26

恢复完，在重建 TiFlash 副本行不

TiDB001 · 2026 年5 月 22 日 14:42

这个要看一下具体日志，报什么错误信息

Horace · 2026 年5 月 23 日 01:12

恢复完之后执行ALTER TABLE db.schema SET TIFLASH REPLICA 0; 清除TiFlash,再次重新SET TiFlash 为1 还是不行1,目前我知道的是我最开始用NFS恢复宕机过一次可能产生碎片记忆在TiFlash了,我现在在试着重新部署TiFlash再试试

独善其身 · 2026 年5 月 23 日 05:53

重新部署了吗？最后怎么样了啊

Horace · 2026 年5 月 25 日 02:58

目前重新部署后只要使用tiflash还会报错1105-Exception,分析报错日志可能是MPP执行时崩溃导致,而且还检测出第一次部署的Tiflash没有清楚干净,我现在正在测试一套新的环境重新是否可以使用Tiflash,而且有一个坑就是备份时使用NFS备份时可以备份亿级的数据,但是数据恢复时如果不使用s3协议而使用NFS恢复亿级数据就会导致崩溃,恢复亿级数据最好是使用MINIO的s3协议或者一些云服务来恢复

Horace · 2026 年5 月 25 日 06:00

我现在已经尝试过删掉所有tiflash旧缓存,文件,已经在中控机上删除所有规则,墓碑文件,包括拉起干净环境重新部署,不管是新建库新建表还是存在的库表,一旦使用tiflash就会报错1105-Exception,而且日志中明确tiflash分给mpp的任务失败:
[2026/05/25 13:18:57.495 +08:00] [WARN] [MPPHandler.cpp:104] [“dispatch task meet error : Exception”] [thread_id=142]
[2026/05/25 13:18:57.495 +08:00] [WARN] [MPPTask.cpp:751] [“Begin abort task: MPP<gather_id:1, query_ts:1779686337493690598, local_query_id:40, server_id:1236, start_ts:466534095244754949,task_id:1>, abort type: ONERROR”] [source=“MPP<gather_id:1, query_ts:1779686337493690598, local_query_id:40, server_id:1236, start_ts:466534095244754949,task_id:1>”] [thread_id=142]
[2026/05/25 13:18:57.495 +08:00] [WARN] [MPPTask.cpp:766] [“Finish abort task from uninitialized”] [source=“MPP<gather_id:1, query_ts:1779686337493690598, local_query_id:40, server_id:1236, start_ts:466534095244754949,task_id:1>”] [thread_id=142]
现在我只在怀疑是不是我只有两台tikv的原因?还多大模型的分析结果是tikv不足3台无法下发tiflash执行

Horace · 2026 年5 月 25 日 08:50

报错大概是MPP没执行tiflash下发的命令,让Gemini给分析,一直是说只有两台tikv的原因,让部署第三台tikv

Raymond · 2026 年5 月 26 日 01:45

你把tiflash 副本设为0，然后再设置为1，是不是很快
如果很快的话，tiflash那边说明没有真正的清理tiflash 副本，你可以设置为0后，过一段时间，再设置为tiflash 副本等于2

Horace · 2026 年5 月 26 日 01:47

是的,如果是新表第一次执行set tiflash 为1的时候可以看到是从0慢慢到1,如果再set为0后从新set为1,就会一秒就执行完了,而且每次使用tiflash的查询都会报错1105-Exception

Raymond · 2026 年5 月 26 日 02:28

所以关键原因还是因为你并没有把tiflash 副本清除干净，你要彻底等tiflash 副本清理干净，再添加副本啊

TiDBer_1834 · 2026 年5 月 26 日 13:05

最后怎么解决的？

TiDBer_AHjy0eKV · 2026 年5 月 27 日 22:57

ALTER TABLE db.schema SET TIFLASH REPLICA 0;

Horace · 2026 年5 月 28 日 00:38

本次用的是测试数据,最后的解决办法是把原库直接drop掉重新跑了一份新库,现在tiflash可用了,问题可能出现在tikv里,具体是什么原因还没弄清楚,也幸好这是测试库

Horace · 2026 年5 月 28 日 00:39

set 为0后再重新set为1,当时还是不行的,最后把库清了重新跑了一份库再用tiflash就好了,当然现在具体什么原因引起的也还没找到

Horace · 2026 年5 月 28 日 00:39

谢谢老师解答副本这一块的问题

菩提老祖 · 2026 年5 月 28 日 10:22

等慢慢清理干净

Raymond · 2026 年5 月 28 日 12:51

不用客气，我这边也是踩过坑的

Fanchen · 2026 年6 月 1 日 08:28

恢复后先重置 TiFlash 副本即可，然后等待同步完成（AVAILABLE=YES）后即可正常使用。

TiDBer_bgWIGhji · 2026 年6 月 2 日 01:32

从架构兼容性角度，如果现有系统依赖 MySQL 生态（ORM、框架、工具链），TiDB 的平滑迁移优势很明显。但分布式系统有内部复杂度，跨节点事务延迟和热点问题需要评估业务模型是否匹配。