Elasticsearch 加新节点反而更卡？💡3步搞定分片迁移，负载均衡

午夜福利合集

5天前发布

010

最近给Elasticsearch（简称ES）集群加了新节点，本想分担压力，结果反而更糟——新创建的分片全往新节点挤，老节点还堆着一大堆历史分片，机器负载差得离谱，查数据越来越慢，属实让人头大！

实则这不是ES“不听话”，而是默认配置没跟上场景。今天就用大白话讲清楚：为啥会这样，以及怎么快速让分片“挪窝”，让所有节点一起干活⚖️。

先搞懂：为啥新节点成了“香饽饽”？

ES有个“默认习惯”：更愿意把新分片分配到“空闲”的节点上。

新节点刚加进来时，磁盘空、CPU闲（妥妥的“空房子”），ES一看“这节点有空”，就把所有新创建的分片全塞过去；

但老节点上的历史分片（列如之前建的100分片索引），ES默认不会主动挪——结果就是新节点被新分片“塞满”，老节点扛着历史分片“喘不过气”，两边都“累得慌”，负载彻底失衡！

3步解决：快速让分片均衡，新老节点一起扛

不用写复杂代码，跟着调配置、看状态就行，小白也能操作！

第一步：先开“自动均衡”开关（关键！）

ES默认会自动均衡分片，但有时候可能被关掉了，先确认并打开它。

打开ES的DevTools（或用curl命令），复制粘贴下面的代码，点执行✅：

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.rebalance.enable": "all" 
  }
}

允许所有分片（新+老）自动挪位

“transient”表明“临时生效”，重启集群后会恢复默认，不用担心改坏配置。

执行后，ES就会开始“思考”：哪些分片该挪到新节点，哪些该从新节点挪去老节点。

第二步：调快“迁移速度”，别等得着急⚡

默认情况下，ES一次只搬2个分片，速度慢得像“蜗牛爬”。我们可以让它“多搬几箱”，但别贪多（不然会占满网络/CPU）。

继续在DevTools里执行：

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.cluster_concurrent_rebalance": 5,
    "cluster.routing.allocation.node_concurrent_recoveries": 5 
  }
}

cluster_concurrent_rebalance 同时搬5个分片（提议5-10之间）

node_concurrent_recoveries 每个节点同时接收5个分片

举个例子：之前1小时才搬10个分片，调完后可能20分钟就能搬完，速度直接翻倍！

第三步：看进度+手动补位（适合小问题）

调完配置后，得知道分片到底挪没挪。用下面的命令看分片分布：

GET /_cat/shards?v

结果里会显示“哪个分片在哪个节点上”，列如看到老节点还有大量历史分片没动，或者新节点的分片还太多，可以手动“挪一下”（适合个别分片卡住的情况）：

POST /_cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "你的索引名",  // 列如之前建的100分片索引
        "shard": 0,             // 要挪的分片编号（从0开始）
        "from_node": "老节点名",// 目前在的节点
        "to_node": "新节点名"  // 要挪去的节点
      }
    }
  ]
}