Elasticsearch千万级文档远程重索引迁移的节流配置与方案咨询

1. 能否将request_per_seconds调整为1000000？ #

直接调到100万风险极高，绝对不建议这么做。

request_per_seconds只是控制reindex每秒发起的请求数，但实际迁移速度的瓶颈从来不是这个参数，而是源集群的读取能力、目标集群的写入能力、跨集群网络带宽，以及集群CPU、内存、磁盘IO的负载上限。1亿条文档的规模下，强行拉满请求数到100万，大概率会引发：

• 源集群搜索请求过载，CPU/磁盘IO打满，直接影响线上业务；
• 目标集群写入队列阻塞，请求超时，甚至节点因内存溢出崩溃；
• 跨集群网络带宽被占满，导致其他业务请求延迟飙升。

正确的做法是逐步试探+监控调优：先把参数调到20万左右，同时紧盯两个集群的核心指标（CPU使用率、磁盘读写速率、搜索/写入延迟、堆内存使用率），如果集群负载在安全阈值内（比如CPU不超70%、延迟无明显飙升），再逐步往上加，直到找到集群能承受的最大安全值。

2. 节流式重索引的更优实现方案 #

分片级并行重索引 #

利用Elasticsearch的slice参数把大任务拆成多个分片级子任务并行执行，每个子任务只处理源索引的一个分片。示例请求：

POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "source_index",
    "slice": {
      "id": 0,
      "max": 8
    }
  },
  "dest": {
    "index": "dest_index"
  },
  "requests_per_second": 50000
}

你可以根据源索引的分片数设置max值（比如源索引有8个分片就设为8），同时给每个子任务单独设置合理的节流值，既提升整体迁移速度，又能精准控制单任务的负载压力。

快照恢复+增量节流同步 #

如果业务允许短时间的低峰期或只读窗口，优先用快照迁移：

1. 给源索引创建快照，上传到共享仓库（比如S3、HDFS）；
2. 在目标集群直接恢复快照，这一步的速度比reindex快一个量级；
3. 最后用reindex同步快照创建之后产生的增量数据，此时仅需处理少量增量，节流的时间影响会非常小。

动态节流+批量调优 #

不要依赖固定的requests_per_second，用脚本（比如Python结合elasticsearch-py库）实现动态调整：

• 每次批量拉取N条文档写入目标集群；
• 每轮请求后查询源/目标集群的负载指标；
• 根据负载情况自动调整批量大小和请求间隔：负载低就增大批量/缩短间隔，负载高就减小批量/延长间隔。

临时优化目标集群写入配置 #

迁移期间临时调整目标索引的参数，降低写入开销：

• 设置index.refresh_interval: -1，关闭自动刷新（迁移完成后再改回原配置）；
• 设置index.number_of_replicas: 0，暂时关闭副本写入（迁移完成后再恢复副本数）；
• 关闭目标索引的不必要分词逻辑、冗余字段映射，减少写入时的计算开销。

内容的提问来源于stack exchange，提问作者Kartik Luthra