配置项作用 #
thread_pool.fetch_shard_started.core 配置项用于控制分片启动状态获取线程池的核心线程数。
此线程池负责在集群重启或节点故障恢复时，异步获取各个节点的分片启动状态信息，是集群恢复过程中的关键组件。
配置项属性 #
- 配置路径:
thread_pool.fetch_shard_started.core - 数据类型:
Integer（整数） - 默认值:
1 - 是否可选: 是
- 作用域: NodeScope（节点级别）
- 动态更新: 是（可以动态更新，无需重启）
配置项详解 #
工作机制 #
Fetch Shard Started 线程池架构
线程池类型: SCALING (可伸缩)
┌─────────────────────────────────────┐
│ Fetch Shard Started 线程池 │
├─────────────────────────────────────┤
│ 核心线程: core (默认 1) │
│ ┌───┐ │
│ │ 1 │ ← 始终保持活跃 │
│ └───┘ │
│ │
│ 弹性线程: max - core │
│ ┌───┬───┬───┬───┐ │
│ │ 2 │ 3 │ 4 │...│ ← 按需创建 │
│ └───┴───┴───┴───┘ │
│ │
│ 最大线程: max (2 × CPU核心数) │
└─────────────────────────────────────┘
使用场景:
1. 集群重启恢复
├── 集群启动
├── 主节点分配分片
├── 询问各节点: "你的分片启动了吗?"
└-- 收集启动状态信息
2. 节点故障恢复
├── 检测节点故障
├── 重新分配分片
├── 询问存活节点: "谁有最新的分片?"
└-- 确定恢复策略
3. 分片分配决策
├── 比较各节点分片版本
├── 确定主分片位置
├── 分配副本分片
└-- 完成恢复
与集群恢复的关系 #
集群恢复流程
节点加入集群:
│
├── GatewayAllocator 启动
├── 需要分配主分片
│ └── 谁拥有最新版本?
│ └── 使用 FetchShardStarted
│
├── 异步查询所有节点
│ ├── 节点1: 你的分片X启动了吗?
│ ├── 节点2: 你的分片X启动了吗?
│ ├── 节点3: 你的分片X启动了吗?
│ └── 并行执行 ✅
│
├── 收集响应
│ ├── 节点1: 版本5
│ ├── 节点2: 版本6 ← 最新
│ └── 节点3: 版本5
│
├── 决策: 节点2作为主分片
│
└── 分配副本给其他节点
线程池作用:
├── 并行查询多个节点
├── 快速收集分片状态
├── 加速集群恢复
└-- 提高可用性
core 设置影响 #
core 值的影响分析
core = 1 (默认):
├── 资源占用: 最小 ✅
├── 恢复速度: 标准
├── 并发查询: 串行启动
└-- 适用: 大多数场景 ✅
core = 2-4:
├── 资源占用: 较小
├── 恢复速度: 快 ✅
├── 并发查询: 可以并行启动
└-- 适用: 大型集群
core > 4:
├── 资源占用: 中等
├── 恢复速度: 更快
├-- 并发查询: 并行能力强
└-- 适用: 超大型集群 (谨慎)
配置建议 #
默认配置（推荐） #
thread_pool:
fetch_shard_started:
core: 1 # 默认值
建议: 大多数场景使用默认值。
大型集群 #
thread_pool:
fetch_shard_started:
core: 2 # 增加核心线程
max: 16
建议: 大型集群或有大量分片的场景。
超大型集群 #
thread_pool:
fetch_shard_started:
core: 4
max: 32
keep_alive: 5m
建议: 超大规模集群，需要快速恢复。
动态更新 #
PUT /_cluster/settings
{
"transient": {
"thread_pool.fetch_shard_started.core": 2
}
}
代码示例 #
基础配置 #
thread_pool:
fetch_shard_started:
core: 1
完整配置 #
thread_pool:
fetch_shard_started:
core: 1
max: 16
keep_alive: 5m
查看线程池状态 #
GET /_cat/thread_pool/fetch_shard_started?v
查看集群恢复状态 #
GET /_cluster/health?wait_for_events=0
GET /_cat/recovery?v
相关配置 #
| 配置项 | 作用 | 默认值 |
|---|---|---|
fetch_shard_started.core | 核心线程数 | 1 |
fetch_shard_started.max | 最大线程数 | 2 × CPU核心数 |
fetch_shard_started.keep_alive | 线程保活时间 | 5m |
注意事项 #
默认值: 默认值为
1，适用于大多数场景。动态更新: 支持动态更新，无需重启。
恢复关键: 影响集群恢复速度。
资源占用: 核心线程始终占用资源。
合理设置: 大型集群可适当增加。
与 max 配合: core 应小于 max。
监控建议: 监控集群恢复时间。
测试验证: 重启后验证恢复速度。
集群一致性: 建议集群中各节点保持一致。
故障恢复: 影响节点故障后的恢复速度。
使用场景 #
场景选择指南
小型集群 (< 10节点):
├── core: 1
├── 分片数: < 1000
├── 恢复需求: 标准
└-- 推荐: 默认配置 ✅
中型集群 (10-50节点):
├── core: 1-2
├── 分片数: 1000-5000
├── 恢复需求: 较快
└-- 推荐: 略微增加
大型集群 (50-200节点):
├── core: 2-4
├── 分片数: 5000-20000
├── 恢复需求: 快速
└-- 推荐: 增加核心线程
超大型集群 (> 200节点):
├── core: 4-8
├── 分片数: > 20000
├── 恢复需求: 极速
└-- 推荐: 重点优化
故障排查 #
恢复慢问题排查
问题: 集群恢复时间过长
排查:
├── 检查线程池状态
│ └── GET /_cat/thread_pool/fetch_shard_started?v
│
├── 检查活跃线程数
├── 检查是否有队列积压
├── 分析集群规模
└-- 评估分片数量
解决:
方案 1: 增加 core ✅
├── 提高并发能力
├── 动态更新
└-- 加速恢复
方案 2: 增加 max ✅
├── 提高最大并发
├── 配合 core 调整
└-- 应对峰值
方案 3: 优化分片分布 ✅
├── 减少分片数量
├── 优化分配策略
└-- 长期方案
方案 4: 检查网络 ✅
├── 节点间网络延迟
├── 带宽限制
└-- 硬件问题
最佳实践 #
Fetch Shard Started 最佳实践
1. 默认配置起步
├── 从 core: 1 开始
├── 观察恢复时间
├── 根据需要调整
└-- 避免过度配置
2. 监控恢复性能
├── 记录集群恢复时间
├── 分析恢复瓶颈
├── 评估线程池效率
└-- 定期审查配置
3. 合理设置 core
├── 小集群保持默认
├── 大集群适当增加
├── 不建议超过 8
└-- 根据分片数量调整
4. 配置 max 和 keep_alive
├── max: 2 × CPU 核心数
├── keep_alive: 5 分钟默认
├── 根据恢复模式调整
└-- 平衡资源和性能
5. 集群一致性
├── 保持各节点一致
├── 避免配置差异
├── 统一更新配置
└-- 定期审查同步
