恢复失败——如何解决此Elasticsearch异常

适用版本： 6.8-8.9

1. 错误异常的基本描述 #

restore failed 表示某个分片已经通过了前置快照校验，并进入恢复执行阶段，但在 prepareForIndexRecovery、openEngineAndRecoverFromTranslog、补齐 sequence number gaps 或 finalizeRecovery 等步骤中出现异常，最终被包装成 IndexShardRestoreFailedException。

这说明问题已经晚于“快照能否恢复”的各种前置校验，真正失败点落在分片恢复执行流程内部。

常见现象 #

restore 请求已被接受，但某些 shard 进入恢复后失败。
日志中通常伴随具体 shardId 和下层 cause。
可能看到部分 shard 成功、部分 shard 失败，索引恢复不完整。
相邻异常常涉及 store 状态、translog、文件恢复或节点关闭。

典型报错与异常栈 #

IndexShardRestoreFailedException: [index][0] restore failed

2. 为什么会发生这个错误 #

源码片段表明，恢复流程已经走到本地分片初始化、打开 engine、回放 translog 和 finalize recovery。只要其中任一步抛错，外层就会把异常包装成 restore failed。

常见原因通常包括：

分片本地 store 准备失败。
恢复中的文件或快照内容读取异常。
translog 回放或 sequence number gap 填充失败。
节点状态变化、store 关闭或资源异常导致 finalize recovery 中断。

3. 如何排查和解决这个异常和解决这个异常 #

建议按“先读下层 cause，再判断失败发生在恢复流程的哪个子阶段”的顺序处理：

查看 restore failed 下层真实异常，确认是 store、文件、translog 还是 finalize recovery 出错。
检查失败 shard 所在节点的磁盘、线程池和关闭事件。
对照 _recovery 输出确认恢复停在哪一阶段。
若只是个别 shard 失败，围绕具体 shard 与节点做局部排查，不要一上来就怀疑整个 snapshot。

排查时需要注意的问题 #

restore failed 是执行层包装异常，关键始终在下层 cause。
不要把它和 failed to restore snapshot [snapshotId] 完全等同，后者更强调按 snapshotId 包装的 restore 失败链路。
若节点正处于关闭、磁盘满或 store 异常状态，单纯重试通常无效。

4. 如何解决这个错误 #

常用修复思路 #

先修复下层 cause 对应的问题，再重试 restore。
对节点资源或 store 状态异常，优先恢复节点健康度。
对源快照或 shard 文件损坏场景，改用其他可用快照恢复。
为恢复任务建立分片级监控，避免只看到 restore 请求提交成功却忽略执行阶段失败。

借助 INFINI 产品提升排障效率 #

INFINI Console 适合关联查看恢复阶段、节点资源与失败 shard 详情。
INFINI Gateway 可帮助识别是否存在重复恢复、异常取消或冲突操作。

5. 小结 #

restore failed 说明 restore 已经进入分片执行阶段。真正要解决的不是外层这句文案，而是恢复过程中具体哪一步失败，以及它对应的节点、store、translog 或 snapshot 读取问题。

附：日志上下文 #

e -> listener.onFailure(new IndexShardRestoreFailedException(shardId, "restore failed", e))

标签

恢复 IndexShardRestoreFailedException 执行失败