Elasticsearch集群全节点滚动重启方案咨询（零停机补丁升级）
2026-5-19
Elasticsearch 2.4.4 零停机滚动重启实操指南（适配你的集群配置）
嘿，针对你描述的ES 2.4.4集群（1主分片+1副本分片、150个索引、20个数据节点+3个主节点），要实现零停机补丁更新的全节点滚动重启，完全可以按照标准的滚动重启流程来操作，核心就是逐个节点重启，确保每一步集群都保持健康可用。下面是适配你集群的具体操作步骤：
准备工作（必做！）
- 先确认集群状态是green，用这个命令查：
curl -XGET 'http://<你的ES地址>:9200/_cluster/health?pretty'，只有green状态才能动手，不然本来就有分片飘着，重启只会添乱。 - 如果业务允许，暂时停一下索引写入（或者确保写入有重试机制），虽然零停机不强制停写，但减少写入能让分片恢复快很多，节省时间。
- 关闭分片自动分配：
这步是为了防止重启节点时，集群瞎折腾把分片移来移去，浪费资源，等节点恢复后再开就行。curl -XPUT 'http://<你的ES地址>:9200/_cluster/settings' -d '{ "persistent": { "cluster.routing.allocation.enable": "none" } }'
先处理主节点（3个）
你的集群有3个主节点，quorum（法定票数）是2，所以逐个重启完全没问题，不会导致集群丢主节点：
- 挑一个主节点，先停服务：
service elasticsearch stop（要是你用systemd就换成systemctl stop elasticsearch，根据自己的部署方式调整） - 等节点完全停掉，再启动它：
service elasticsearch start - 等节点重新加入集群，用
curl -XGET 'http://<你的ES地址>:9200/_cat/nodes?v'确认它在线，而且集群状态回到green - 重复上面的步骤，把另外两个主节点也挨个重启，一定要等前一个完全恢复再搞下一个！
再处理数据节点（20个）
因为你的索引都是1主1副，每个分片都有备份，所以重启单个数据节点时，对应的分片会自动切到副本节点，完全不影响业务访问：
- 选一个数据节点，停服务：
service elasticsearch stop - 等节点停稳，启动它：
service elasticsearch start - 等节点回到集群，用
_cat/nodes确认在线 - 再等这个节点上的分片全部恢复完成，最简单的就是等集群回到green：
curl -XGET 'http://<你的ES地址>:9200/_cluster/health?wait_for_status=green&timeout=300s'，或者用_cat/shards看有没有未分配的分片 - 就这么重复，把剩下的19个数据节点挨个重启，绝对不能同时搞多个节点，哪怕你手速快也不行！
收尾工作
所有节点都重启完后，记得开启分片自动分配：
curl -XPUT 'http://<你的ES地址>:9200/_cluster/settings' -d '{ "persistent": { "cluster.routing.allocation.enable": "all" } }'
- 再检查一遍集群状态是green，确保所有分片都乖乖待在正确的节点上
- 如果之前停了写入，现在可以恢复正常业务了
一些关键提醒
- 千万不要同时重启多个节点！尤其是数据节点，哪怕有副本，同时搞多个可能会导致某个分片的主副都被重启，短暂丢数据或者不可用，违背零停机的初衷。
- ES 2.4.4的分片恢复速度可以调一下，比如把
indices.recovery.max_bytes_per_sec设成100mb（默认是20mb），能加快恢复，但别设太大，不然集群扛不住。 - 每个节点重启后一定要等集群回到green再进行下一步，150个索引的分片恢复需要点时间，耐心等，别着急。
- 如果中途集群变成yellow，不用慌，大概率是分片在恢复，等会儿就自动回green了；要是很久没回来，再去查
_cluster/allocation/explain找原因。
内容的提问来源于stack exchange，提问作者CorribView
