适用版本： 7.16-8.9
1. 错误异常的基本描述 #
在从快照恢复分片时，Elasticsearch 会并行下载和应用快照文件。如果发现某些下载失败，或者恢复中的文件状态与源索引文件不再一致，它会取消当前这一轮文件恢复，等待飞行中的请求收尾后再重置恢复流程。此时常见异常就是 Recover snapshot files cancelled。
常见现象 #
- 快照恢复过程中中断，但不是简单的“目标分片不存在”。
- 恢复日志中往往伴随文件下载失败、校验不一致或底层 I/O 报错。
- 某些场景下 Elasticsearch 会改为回退并重新从源节点文件恢复，而不是继续使用当前快照文件流。
典型报错与异常栈 #
org.elasticsearch.common.util.CancellableThreads$ExecutionCancelledException: Recover snapshot files cancelled
2. 为什么会发生这个错误 #
代码注释已经给出信号：当部分快照文件下载失败，导致“已恢复的快照文件”和“源索引文件”不再一致时，当前恢复必须整体取消并重来。这通常意味着恢复过程中的文件级一致性已被打破。
常见根因包括：
- 仓库到目标节点的网络传输中断或超时。
- 对象存储读失败、文件损坏或短时不可用。
- 恢复过程中分片状态变化，导致当前恢复上下文失效。
- 节点负载高、磁盘 I/O 异常，造成部分文件落地失败。
3. 如何排查和解决这个异常和解决这个异常 #
- 先检查恢复状态：
GET /_recovery?active_only=true&detailed=true
- 结合节点日志查看在取消前的真正失败原因，通常在更早的
Caused by中。 - 如果是快照仓库恢复，检查仓库连通性和对象存储读取稳定性。
- 观察目标节点磁盘、网络和线程池是否在恢复时出现资源瓶颈。
- 如果恢复被反复取消，排查是否同时存在节点重启、分片重新分配或恢复来源切换。
排查时需要注意的问题 #
Recover snapshot files cancelled通常是恢复控制流的结果，不是第一现场根因。- 真正的原因往往在此前的文件下载失败、校验失败或 I/O 异常日志里。
- 只盯着最后这条取消异常，容易忽略真正导致恢复重置的前序错误。
4. 如何解决这个错误 #
常用修复思路 #
- 优先修复底层文件读取失败的原因，例如对象存储权限、网络超时、磁盘问题。
- 避免在节点资源紧张或频繁重分配期间执行大规模恢复。
- 必要时降低并发恢复压力，给节点更多磁盘和网络余量。
- 底层问题修复后重新触发恢复，让系统走一次完整、稳定的恢复流程。
相关 Elasticsearch API #
GET /_recovery?active_only=true&detailed=true：查看恢复进度与失败点。GET /_snapshot/{repository}/{snapshot}：确认恢复来源快照是否正常。GET /_cat/shards?v：查看分片是否因状态变化导致恢复上下文切换。
借助 INFINI 产品提升排障效率 #
- INFINI Console 有助于把恢复失败、节点资源波动和仓库异常日志串在一起看。
- INFINI Gateway 适合追踪恢复相关管理请求的重试与失败链路。
5. 小结 #
Recover snapshot files cancelled 说明当前快照文件恢复已经被系统主动放弃，准备回退重来。它通常不是根因本身，而是前面文件下载失败或一致性校验异常的结果。排查重点应放在取消前的底层 I/O 和仓库访问错误上。
相关错误 #
- recovery was canceled reason [reason]：文件恢复取消往往会在更上层体现为恢复被中止
- failed to fetch index version after copying it over：文件已经复制下来，但后续索引读取仍可能失败
- index is unrecoverable：如果底层目录已坏到无法继续，最终会落到不可恢复
- cannot restore partial index：恢复半途失败后经常遗留 partial index
- cannot restore index [index] because it cannot be upgraded：即使文件能拿到，索引元数据不兼容也会让恢复继续失败
附：日志上下文 #
assert this.cancelled.get();
throw new CancellableThreads.ExecutionCancelledException("Recover snapshot files cancelled");
