恢复并发操作数配置

配置项作用 #

indices.recovery.max_concurrent_operations 配置项用于控制在索引恢复过程中，源节点到目标节点可以并发发送的操作块（operation chunk）请求的最大数量。

此配置限制并发操作块请求数量，控制恢复过程中的内存使用和网络带宽消耗。

配置项属性 #

• 配置路径: indices.recovery.max_concurrent_operations
• 数据类型: Integer（整数）
• 默认值: 1
• 最小值: 1
• 最大值: 4
• 是否可选: 是
• 作用域: NodeScope（节点级别）
• 动态更新: 是（支持动态更新）

配置项详解 #

工作机制 #

操作块传输流程

max_concurrent_operations = 1:

事务日志操作:
[op1][op2][op3][op4][op5]
    │
    ↓ 串行发送
op1 ──→ 目标节点
    │
    ↓ 等待响应
    │
    ↓
op2 ──→ 目标节点
    │
    ↓
...

逐个发送，每次 1 个操作


max_concurrent_operations = 3:

事务日志操作:
[op1][op2][op3][op4][op5]
    │
    ↓ 并发发送
├────── op1 ──→ 目标节点
├────── op2 ──→ 目标节点
└────── op3 ──→ 目标节点
    │
    ↓ 等待响应
    │
    ↓ 继续发送

操作块与文件块 #

恢复过程中的两种并发控制

1. 操作块并发 (max_concurrent_operations)
   └── 事务日志操作的并发发送
   └── 控制逻辑: OperationBatchSender

2. 文件块并发 (max_concurrent_file_chunks)
   └── 文件数据块的并发发送
   └── 控制逻辑: MultiChunkTransfer

两者协同工作，确保恢复过程稳定

并发限制逻辑 #

OperationBatchSender 限制

canSendBatch = true

while (canSendBatch) {
    发送操作批次
        │
        ├──── 未达到限制 ──→ 继续发送 ✅
        │
        └──── 达到限制 ──→ 等待响应 ⏸
}

max_concurrent_operations:
1 ──→ 等待 op1 响应
2 ──→ 等待 op2 响应
3 ──→ 等待 op3 响应
4 ──→ ... (不能发送新操作)

op1 响应返回 ─→ 可以发送 op4

配置建议 #

生产环境（默认） #

indices:
  recovery:
    max_concurrent_operations: 1  # 默认值

建议: 保持默认值 1。保守配置确保稳定性。

高性能网络 #

indices:
  recovery:
    max_concurrent_operations: 3  # 3 个并发

建议: 增加到 2-3。网络性能优异时使用。

快速恢复要求 #

indices:
  recovery:
    max_concurrent_operations: 4  # 最大值

建议: 设置为 4。需要最快恢复速度时使用。

内存受限环境 #

indices:
  recovery:
    max_concurrent_operations: 1  # 保持最小

建议: 保持默认值。目标节点内存受限时使用。

代码示例 #

easysearch.yml 基础配置 #

indices:
  recovery:
    max_concurrent_operations: 1

高性能配置 #

indices:
  recovery:
    max_concurrent_operations: 3
    max_concurrent_file_chunks: 5

保守配置 #

indices:
  recovery:
    max_concurrent_operations: 1
    max_concurrent_file_chunks: 1

动态更新配置 #

PUT /_cluster/settings
{
  "transient": {
    "indices.recovery.max_concurrent_operations": 2
  }
}

相关配置 #

恢复阶段说明 #

索引恢复的两个阶段

阶段 1: 事务日志恢复
├── 发送事务操作
├── 并发控制: max_concurrent_operations
└── 操作完成后才能进入下一阶段

阶段 2: 文件数据恢复
├── 发送文件数据
├── 并发控制: max_concurrent_file_chunks
└── 完成后恢复成功

两个阶段的并发控制是独立的

性能影响分析 #

恢复时间估算 #

假设需要恢复 1000 个操作

max_concurrent_operations = 1:
每批 1 个操作
需要 1000 批
每次往返 10ms
总时间 ≈ 1000 × 10ms = 10 秒


max_concurrent_operations = 2:
每批 2 个操作
需要 500 批
每次往返 10ms
总时间 ≈ 500 × 10ms = 5 秒


max_concurrent_operations = 4:
每批 4 个操作
需要 250 批
每次往返 10ms
总时间 ≈ 250 × 10ms = 2.5 秒

使用场景 #

推荐使用默认值的场景 #

• 标准生产: 正常的恢复需求
• 网络一般: 网络延迟中等
• 保守策略: 优先考虑稳定性

推荐增加并发数的场景 #

• 高速网络: 低延迟、高带宽网络
• 快速恢复: 需要尽快完成恢复
• 充足资源: 节点内存和网络充足

推荐保持最小值的场景 #

• 慢速网络: 高延迟或低带宽网络
• 内存受限: 目标节点内存有限
• 不稳定网络: 网络质量不稳定

与文件块并发的配合 #

两种并发控制的关系

max_concurrent_operations = 2
max_concurrent_file_chunks = 3

阶段 1: 事务日志恢复
并发发送 2 个操作块
等待响应后继续

阶段 2: 文件数据恢复
并发发送 3 个文件块
等待响应后继续

两者独立控制:
- 操作块: 事务日志操作的并发
- 文件块: 文件数据块的并发

注意事项 #

1. 默认值: 默认值为 1，最保守的配置。

2. 范围限制: 最小值为 1，最大值为 4。

3. 动态更新: 支持动态更新，修改后立即生效。

4. 与操作块配合: 只影响事务日志操作的并发。

5. 与文件块配合: 需要与 max_concurrent_file_chunks 配合配置。

6. 网络条件: 根据网络延迟和带宽调整配置。

7. 资源考虑: 增加并发会增加目标节点的负载。

8. 恢复类型: 影响索引恢复、副本恢复、快照恢复。

9. 监控建议: 监控恢复过程的速率和成功率。

10. 测试验证: 配置变更后应进行恢复测试验证。