版本说明

以下参数在 Elasticsearch 7.x/8.x 均有效，均为集群级 persistent 设置。

1. 为什么恢复会慢

节点重启、新节点加入、副本重新分配这些场景下，ES 需要把分片数据从一个节点搬到另一个节点（recovery）。默认配置是偏保守的——ES 假设你的集群网络/磁盘 I/O 资源紧张，宁可恢复慢一点也不要抢占正常读写请求的资源。但如果你的集群硬件本身有富余（比如内网万兆网络、SSD），保守的默认值反而会让一次节点重启后的恢复过程拖上几个小时，期间集群处于 yellow/red 状态，风险窗口被人为拉长。

三个参数分别控制恢复过程的并发度和限速，需要配合调整才有效。

2. node_concurrent_recoveries：单节点并发恢复的分片数

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation.node_concurrent_recoveries": 8
      }
    }
  }
}

控制每个节点同时能作为源或目标参与恢复的分片数量，默认值通常是 2。调大它可以让一个节点同时并行搬运更多分片，但要注意：并发恢复的分片越多，该节点在恢复期间要分担的磁盘 I/O 和网络带宽也越多——调得过大反而会因为资源争抢导致每个分片恢复得更慢，得配合硬件实际吞吐能力调整，不是越大越好。

3. cluster_concurrent_rebalance：集群级并发再均衡分片数

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation.cluster_concurrent_rebalance": 8
      }
    }
  }
}

控制整个集群同时进行 rebalance（数据在节点间重新分布，不同于故障恢复但机制类似）的分片数量上限。这个是全局限制，node_concurrent_recoveries 是单节点限制，两者需要一起放大才能让恢复真正提速——只调其中一个，另一个会成为新的瓶颈。

4. indices.recovery.max_bytes_per_sec：单次恢复的限速带宽

PUT _cluster/settings
{
  "persistent": {
    "indices.recovery.max_bytes_per_sec": "500mb"
  }
}

限制恢复过程占用的带宽上限，默认值通常只有 40MB/s（非常保守，专为避免抢占业务流量设计）。如果集群网络是内网万兆且当前业务压力不大，可以放大到几百 MB/s 大幅缩短恢复时间；但这个值调得越大，恢复期间业务查询/写入争抢到的带宽就越少，需要在"尽快恢复绿色状态"和"不影响当前业务"之间权衡。

5. 验证

调整后，观察恢复进度和速度是否明显提升：

GET _cat/recovery?v&active_only=true

关注 bytes_percent（已恢复字节的百分比）随时间的增长速度，以及集群整体状态：

GET _cluster/health

status 从 red/yellow 变为 green 且 relocating_shards/initializing_shards 归零，说明恢复已完成。

6. 坑

• 这三个参数是"加速旋钮"而非"免费午餐"——恢复期间集群会消耗更多 CPU/内存/磁盘 I/O/网络带宽，如果此时业务查询压力也很大，调得过猛可能导致恢复没结束、正常查询先超时了。建议在业务低峰期做这类临时调优，恢复完成后视情况改回默认值，而不是把加速参数当成永久配置。
• 三个参数必须配合调整：只调 max_bytes_per_sec 不调并发数，或者只调并发数不放开带宽限速，实际提速效果都有限，因为总有一个维度会先成为瓶颈。

7. 可复用要点

1. ES 恢复慢的默认值是刻意保守的，硬件有富余时可以主动调优，而不是被动等待。
2. 并发度（node/cluster 两级）和带宽限速要一起调，单独调一个容易被另一个卡住。
3. 加速配置是临时手段，恢复完成后应视业务压力决定是否改回默认值，避免长期占用过多资源。