适用版本： 6.8-7.17
1. 错误异常的基本描述 #
Restore process is already running in this cluster 表示你尝试发起新的快照恢复时，集群中已经存在一个活跃的 restore 过程。根据源码，在 7.0 之前的版本中，如果 RestoreInProgress 非空，就会直接抛出 ConcurrentSnapshotExecutionException，拒绝并发恢复。
这是一条恢复流程层面的并发保护规则，不是仓库不可用或快照损坏。
常见现象 #
- 发起第二个 restore 请求时立即返回
409或并发执行异常。 - 集群中已有索引或数据流正在从快照恢复。
- 自动化恢复脚本和人工恢复操作重叠时，后一条请求被直接拒绝。
- 在旧版本集群里更容易遇到“整个集群一次只允许一个 restore 过程”的限制。
典型报错与异常栈 #
ConcurrentSnapshotExecutionException: [repo:snap-20260331] Restore process is already running in this cluster
2. 为什么会发生这个错误 #
Elasticsearch 需要在 restore 期间维护集群级恢复状态和分片分配流程。旧版本中为了避免多个恢复流程互相覆盖状态，直接限制同一时间只能有一个 restore 过程在集群里推进。
常见原因通常包括：
- 前一个 restore 仍在执行，而新的恢复请求被过早提交。
- 自动化批量恢复没有做排队或串行控制。
- restore 过程因大索引、慢仓库或资源紧张而持续时间较长。
- 运维误以为 restore 请求提交成功后即可立刻发起下一次恢复。
3. 如何排查和解决这个异常和解决这个异常 #
建议按“先确认当前 restore 是否仍活跃，再决定等待、串行化还是拆分窗口”的顺序处理：
- 查看
RestoreInProgress或 recovery 状态，确认当前已有哪个 restore 在跑。 - 判断它是正常执行中，还是卡住了。
- 如果是正常执行，等待完成后再提交新的 restore。
- 如果脚本频繁撞上该错误，改为串行调度而不是并发提交。
相关 Elasticsearch API #
GET /_cluster/state：查看 restore 相关状态。GET /_recovery：确认当前恢复进度。GET /_snapshot/{repository}/_current：辅助判断快照与恢复窗口是否重叠。
排查时需要注意的问题 #
- 这是 restore 入口阶段的并发限制，不要误判成分片恢复失败。
- 如果 restore 已卡死，核心问题是前一个恢复为什么没结束，而不是新请求本身。
- 不同版本对并发恢复的限制不同，排查时要先确认集群版本。
4. 如何解决这个错误 #
常用修复思路 #
- 等待当前 restore 完成后再发起下一次恢复。
- 将批量恢复改为串行调度。
- 若前一个 restore 异常拖长，先解决其底层恢复问题。
- 在运维流程中把 restore 和其他高风险迁移操作错峰执行。
借助 INFINI 产品提升排障效率 #
- INFINI Console 适合统一查看恢复进度、分片状态和 restore 异常时间线。
- INFINI Gateway 可帮助识别是哪些上游任务在并发触发 restore。
5. 小结 #
Restore process is already running in this cluster 的核心是 restore 并发控制，不是仓库读写问题。处理重点是找到当前占用恢复窗口的任务，并把恢复流程做串行化或错峰化。
相关错误 #
- 空恢复源：恢复请求通过后进入分片恢复阶段的相邻异常
- 恢复时无法修改设置k：restore 请求参数校验失败的另一条入口分支
- 无法在恢复时移除设置：restore 参数中 ignore_index_settings 的相邻校验分支
- 无法在 restore 期间删除快照：恢复进行中触发的另一条并发保护规则
附：日志上下文 #
if (restoreInProgress.isEmpty() == false) {
throw new ConcurrentSnapshotExecutionException(snapshot, "Restore process is already running in this cluster");
}
