跟随者恢复最大并发文件块数配置

配置项作用 #

replication.follower.index.recovery.max_concurrent_file_chunks 配置项用于控制跟随者索引恢复时最大并发文件块传输数。

当 Follower 索引从 Leader 集群恢复数据时，多个文件块可以并行传输。此配置决定了可以同时传输多少个块，直接影响恢复速度和资源消耗。

配置项属性 #

• 配置路径: replication.follower.index.recovery.max_concurrent_file_chunks
• 数据类型: Integer（整数值）
• 默认值: 5
• 最小值: 1
• 是否可选: 是
• 作用域: NodeScope（节点级别）
• 动态更新: 是（可以动态更新，无需重启）

配置项详解 #

工作机制 #

并发块传输机制

max_concurrent_file_chunks = 5 (默认):

文件列表:
├── segment_1 (100MB)
├── segment_2 (80MB)
├── segment_3 (120MB)
├── segment_4 (50MB)
├── segment_5 (90MB)
├── segment_6 (70MB)
└── ...


传输过程:
1. 启动 5 个并发传输
   ├── Transfer 1: segment_1, chunk 1
   ├── Transfer 2: segment_2, chunk 1
   ├── Transfer 3: segment_3, chunk 1
   ├── Transfer 4: segment_4, chunk 1
   └── Transfer 5: segment_5, chunk 1


2. 完成一个传输
   Transfer 1 完成
   └── 立即启动下一个
       └── Transfer 6: segment_6, chunk 1


3. 持续传输
   ├── 保持 5 个并发
   ├── 直到所有文件传输完成
   └── 最大化网络和磁盘利用

资源使用计算 #

资源使用分析

内存使用:
总内存 = chunk_size × max_concurrent_file_chunks


配置 1 (默认):
├── chunk_size: 10mb
├── concurrent: 5
├── 总内存: 50mb
└── 适合大多数 ✅


配置 2 (高性能):
├── chunk_size: 100mb
├── concurrent: 10
├── 总内存: 1gb
└── 需要充足内存


配置 3 (低资源):
├── chunk_size: 5mb
├── concurrent: 2
├── 总内存: 10mb
└── 适合内存受限 ✅


网络使用:
总带宽 = 单个传输速度 × concurrent_chunks


磁盘 I/O:
并发写入 = concurrent_chunks

与块大小的配合 #

chunk_size 和 concurrent_chunks 的配合

方案 1 (默认):
├── chunk_size: 10mb
├── concurrent: 5
├── 总内存: 50mb
├── 吞吐: 适中 ✅
└── 推荐


方案 2 (高吞吐):
├── chunk_size: 50mb
├── concurrent: 10
├── 总内存: 500mb
├── 吞吐: 很高 ✅
└── 需要资源


方案 3 (低内存):
├── chunk_size: 5mb
├── concurrent: 2
├── 总内存: 10mb
├── 吞吐: 较低
└── 安全配置


方案 4 (平衡):
├── chunk_size: 20mb
├── concurrent: 5
├── 总内存: 100mb
├── 吞吐: 较高 ✅
└── 平衡选择

配置建议 #

生产环境（默认） #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 5  # 默认值

建议: 保持默认值 5。适合大多数场景。

高性能环境 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 10  # 增加并发
        chunk_size: 100mb

建议: 高速网络且有充足内存时使用。

内存受限环境 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 2  # 减少并发
        chunk_size: 5mb

建议: 内存受限时减少并发数和块大小。

广域网环境 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 1  # 单连接
        chunk_size: 10mb

建议: 跨地域或不稳定网络使用单连接。

代码示例 #

easysearch.yml 基础配置 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 5

高性能配置 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 10
        chunk_size: 100mb

内存受限配置 #

replication:
  follower:
    index:
      recovery:
        max_concurrent_file_chunks: 2
        chunk_size: 5mb

动态更新配置 #

// 运行时更新
PUT /_cluster/settings
{
  "persistent": {
    "replication.follower.index.recovery.max_concurrent_file_chunks": 8
  }
}

完整恢复配置 #

replication:
  follower:
    index:
      recovery:
        chunk_size: 10mb
        max_concurrent_file_chunks: 5

相关配置 #

性能影响分析 #

恢复速度对比 #

恢复速度对比

场景: 恢复 10GB 索引
网络: 1Gbps
单文件传输: 100MB/s

concurrent = 1:
├── 单线程传输
├── 速度: 100MB/s
├── 时间: 100s ❌
└── 内存: chunk_size


concurrent = 2:
├── 双线程传输
├── 速度: 200MB/s
├── 时间: 50s
└── 内存: 2 × chunk_size


concurrent = 5 (默认):
├── 五线程传输
├── 速度: 400MB/s (假设有带宽限制)
├── 时间: ~30s ✅
└── 内存: 5 × chunk_size


concurrent = 10:
├── 十线程传输
├── 速度: 500MB/s (带宽饱和)
├── 时间: ~25s ✅
└── 内存: 10 × chunk_size


线性效应:
├── 1→5: 显著提升 ✅
├── 5→10: 有提升
├── 10+: 带宽饱和
└── 建议: 根据带宽调整

使用场景 #

推荐使用默认值的场景 #

• 标准部署: 大多数生产环境
• 中等网络: 标准数据中心网络
• 平衡要求: 需要平衡速度和资源

推荐增加并发的场景 #

• 高速网络: 数据中心内部、10Gbps+
• **大索引恢复: 大量数据快速恢复
• 充足内存: 有足够内存资源
• 时间敏感: 需要尽快完成恢复

推荐减少并发的场景 #

• 内存受限: 可用内存有限
• 慢速网络: 带宽受限的网络
• 不稳定网络: 连接不稳定
• 长时间可接受: 不急于完成恢复

注意事项 #

1. 默认值: 默认值为 5，适合大多数场景。

2. 动态更新: 可以动态更新，下次恢复生效。

3. 内存使用: 总内存与 chunk_size 和并发数成正比。

4. 网络带宽: 应根据可用带宽调整并发数。

5. 磁盘 I/O: 高并发会增加磁盘 I/O 压力。

6. 最小值: 最小值为 1，不能设置为 0。

7. 配合调整: 应与 chunk_size 配合调整。

8. 监控建议: 监控恢复进度和资源使用。

9. 网络质量: 不稳定网络建议减少并发。

10. 测试验证: 新环境应测试不同并发数。

故障排查 #

常见问题排查

问题 1: 恢复速度慢

检查:
├── max_concurrent_file_chunks 设置
├── 网络带宽使用
├── 磁盘 I/O 状态
└── CPU 使用


解决:
├── 增加 max_concurrent_file_chunks
├── 检查网络瓶颈
├── 优化磁盘 I/O
└── 调整 chunk_size


问题 2: 内存不足

检查:
├── max_concurrent_file_chunks
├── chunk_size
├── 可用内存
└── JVM 堆内存


计算:
总内存 = chunk_size × max_concurrent_file_chunks


解决:
├── 减少 max_concurrent_file_chunks
├── 减少 chunk_size
├── 增加 JVM 堆
└── 或分批恢复


问题 3: 网络拥塞

检查:
├── 并发连接数
├── 网络带宽
├── 其他流量
└── 网络错误


解决:
├── 减少 max_concurrent_file_chunks
├── 减少 chunk_size
├── 错峰恢复
└── 优化网络

最佳实践 #

恢复配置最佳实践

1. 标准部署
   recovery:
     max_concurrent_file_chunks: 5
     chunk_size: 10mb

   ├── 默认配置
   ├── 内存: ~50MB
   └── 适合大多数 ✅


2. 高性能环境
   recovery:
     max_concurrent_file_chunks: 10
     chunk_size: 100mb

   ├── 快速恢复
   ├── 内存: ~1GB
   └── 数据中心 ✅


3. 低资源环境
   recovery:
     max_concurrent_file_chunks: 2
     chunk_size: 5mb

   ├── 低内存
   ├── 总内存: ~10MB
   └── 资源受限 ✅


4. 广域网
   recovery:
     max_concurrent_file_chunks: 1
     chunk_size: 10mb

   ├── 稳定优先
   ├── 单连接
   └── 跨地域 ✅


5. 配置建议
   ├── 总内存 ≤ 堆内存 10%
   ├── 根据网络带宽调整并发
   ├── 根据内存调整并发和块大小
   └── 监控和调优

调优指南 #

恢复性能调优

1. 评估环境
   ├── 可用内存
   ├── 网络带宽
   ├── 磁盘 I/O
   └── 恢复时间要求


2. 计算资源
   单传输内存 = chunk_size
   总内存 = 单传输内存 × concurrent_chunks
   建议: 总内存 ≤ 堆内存 10%


3. 选择并发数
   ├── 内存充足 / (10% 堆 / chunk_size)
   ├── 例如: 1GB / 100MB = 10
   └── 向下取整


4. 选择块大小
   ├── 高速网络: 50-100mb
   ├── 标准: 10mb
   ├── 低速: 1-5mb
   └── 根据网络选择


5. 测试验证
   ├── 小规模测试
   ├── 监控指标
   ├── 调整配置
   └── 大规模应用