Rolling restart / rolling upgrade (node by node, without unnecessary shard moves)

Command

# 1) Disable replica allocation (only primaries are allocated):
PUT _cluster/settings
{
  "persistent": { "cluster.routing.allocation.enable": "primaries" }
}
# 2) Optional: stop indexing and flush to speed up recovery:
POST _flush
# 3) Stop one node, do the maintenance, start it; verify it joined:
GET _cat/nodes?v&h=name,version,node.role,master,heap.percent
# 4) Re-enable allocation:
PUT _cluster/settings
{
  "persistent": { "cluster.routing.allocation.enable": null }
}
# 5) Wait for green before moving to the next node:
GET _cluster/health?wait_for_status=green&timeout=10m

What it does

Gives the order for restarting or upgrading nodes one at a time while preventing replicas from being recopied to other nodes when a node is down; when the node returns, shards recover quickly from the local copy.

When to use it

When restarting nodes in sequence for an OS patch, JVM/heap change, elasticsearch.yml change or a minor/major version upgrade.

Caution

Do not move to the next node without waiting for green; with two nodes down at once, all copies of a shard may be gone. Restart master-eligible nodes last and one at a time; if the majority is lost the cluster cannot elect a master. If you forget to re-enable allocation.enable, replicas stay unassigned. During an upgrade, data nodes are upgraded first (frozen/cold first, hot last), then masters.