针对你遇到的200GB数据迁移耗时1.5小时的问题，结合ES集群的运行机制，这里有几个经过实践验证的调优方向，能有效缩短数据传输时间：

1. 调优分片恢复的核心参数 #

ES的分片复制速度默认是保守设置，避免占用过多资源，我们可以针对性调高这些参数：

• 调整节点并发恢复数：修改cluster.routing.allocation.node_concurrent_recoveries，默认值是2，可以根据节点的CPU和内存情况调高到4-6。这个参数控制单个节点同时进行的分片恢复任务数，适当提升能增加并行度。
• 提升单恢复任务的带宽上限：修改indices.recovery.max_bytes_per_sec，默认是40mb，如果你集群的网络带宽充足（比如万兆网），可以调到100mb甚至200mb。注意不要超过实际网络带宽的70%，避免影响其他业务。
• 增加分片恢复的并发流：修改indices.recovery.concurrent_streams，默认是3，调高到5-8。这个参数控制单个分片恢复时的并发数据流数量，能加速大分片的传输。

这些参数可以通过集群API临时修改，比如：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.node_concurrent_recoveries": 5,
    "indices.recovery.max_bytes_per_sec": "100mb",
    "indices.recovery.concurrent_streams": 6
  }
}

迁移完成后记得改回默认值，避免影响集群日常稳定性。

2. 优化网络与硬件瓶颈 #

数据迁移的速度很大程度依赖底层硬件和网络：

• 确保节点间用高速网络：如果旧节点和新节点在同一可用区，优先使用万兆以太网连接，避免跨AZ的带宽限制和延迟。如果必须跨AZ，确认云服务商提供的跨AZ带宽足够支撑大流量传输。
• 用SSD替代HDD：如果旧节点仍使用机械硬盘，数据读取和写入的IO瓶颈会严重拖慢复制速度，换成SSD能大幅提升磁盘IO性能。
• 释放旧节点资源：迁移期间暂时关闭旧节点上的非必要服务（比如Kibana、监控代理等），让CPU、内存和IO全力处理分片传输任务。

3. 优化迁移执行策略 #

调整迁移的步骤顺序，避免集群资源竞争：

• 分批次添加新节点：不要一次性加入3个新节点，先加1个，等这个节点的分片复制完成80%以上，再加入下一个。这样能避免集群同时启动大量分片恢复任务，导致资源耗尽。
• 先将旧节点设为非数据节点：在排除旧节点前，先把旧节点的data属性设为false，让集群不再向这些节点分配新分片，集中资源迁移现有分片：

PUT /_nodes/OLD_NODE_ID/_settings
{
  "persistent": {
    "node.data": false
  }
}

等旧节点上的所有分片都迁移到新节点后，再执行排除IP的操作。

4. 临时关闭非必要集群功能 #

迁移期间临时关闭一些消耗资源的功能，减少干扰：

• 调大索引刷新间隔：把index.refresh_interval临时设为30s或更长（默认是1s），减少频繁的磁盘写入操作：

PUT /*/_settings
{
  "index.refresh_interval": "30s"
}

• 关闭自动快照：如果集群开启了自动快照，迁移期间暂时禁用，避免快照任务占用磁盘IO和带宽。
• 临时调整分片分配规则（谨慎操作）：如果新节点是按规划添加的，可以临时设置cluster.routing.allocation.enable: "primaries"，只允许主分片分配，等主分片都迁移到新节点后再恢复副本，不过这个操作要谨慎，确保不会影响集群可用性。

注意事项 #

• 所有参数调整都要逐步进行，每调整一次就观察集群的CPU、内存、磁盘IO和网络带宽指标，避免过度调优导致集群崩溃。
• 迁移完成后，一定要把所有临时修改的参数恢复到默认值，保证集群日常运行的稳定性。

内容的提问来源于stack exchange，提问作者Vlad Cenan