Rolling upgrades in Elasticsearch - Step-by-Step Execution

Concept Flow - Rolling upgrades

Start: Current Cluster Version

↓

Select Node for Upgrade

↓

Take Node Out of Cluster

↓

Upgrade Node Software

↓

Restart Node with New Version

↓

Node Rejoins Cluster

↓

Verify Cluster Health

↓

Repeat for Next Node

↓

All Nodes Upgraded

↓

Upgrade Complete

Rolling upgrades upgrade one node at a time to keep the cluster running without downtime.

Execution Sample

Elasticsearch

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
}

Disables shard allocation temporarily to safely upgrade a node.

Execution Table

Step	Action	Node State	Cluster State	Result
1	Select node1 for upgrade	node1 active	All nodes active	Ready to upgrade node1
2	Disable shard allocation	node1 active	Allocation disabled	Prevents shard movement
3	Stop node1	node1 stopped	Cluster yellow	Node1 offline, cluster still running
4	Upgrade node1 software	node1 stopped	Cluster yellow	Node1 upgraded
5	Start node1 with new version	node1 active (new version)	Cluster recovering	Node1 rejoins cluster
6	Enable shard allocation	node1 active	Allocation enabled	Cluster rebalances shards
7	Verify cluster health	All nodes active	Cluster green	Node1 upgrade successful
8	Repeat steps 1-7 for node2	node2 active	Cluster green	Node2 upgraded
9	Repeat steps 1-7 for node3	node3 active	Cluster green	Node3 upgraded
10	All nodes upgraded	All nodes active (new version)	Cluster green	Rolling upgrade complete

💡 All nodes upgraded one by one, cluster remains available throughout

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	After Step 10
node1 state	active	stopped	active (new version)	active (new version)	active (new version)
cluster allocation	enabled	disabled	disabled	enabled	enabled
cluster health	green	yellow	yellow	green	green

Key Moments - 3 Insights

Why do we disable shard allocation before stopping a node?

Disabling shard allocation (see step 2 in execution_table) prevents shards from moving around during the node upgrade, avoiding extra load and instability.

What happens to cluster health when a node is stopped?

Cluster health changes from green to yellow (step 3) because one node is offline, but the cluster remains available.

Why upgrade nodes one at a time instead of all at once?

Upgrading one node at a time (steps 1-9) keeps the cluster running and avoids downtime, ensuring continuous availability.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cluster health after stopping node1 (step 3)?

A green

B yellow

C red

D unknown

💡 Hint

Check the 'Cluster State' column at step 3 in the execution_table.

At which step is shard allocation re-enabled during the upgrade of node1?

A Step 2

B Step 4

C Step 6

D Step 8

💡 Hint

Look for 'Enable shard allocation' action in the execution_table.

If shard allocation was not disabled before stopping a node, what would likely happen?

A Shards would move causing extra load and instability

B Cluster health would remain green

C Node would upgrade faster

D Nothing changes

💡 Hint

Refer to the key_moments explanation about disabling shard allocation.

Concept Snapshot

Rolling upgrades upgrade one node at a time.
Disable shard allocation before stopping a node.
Stop, upgrade, restart node with new version.
Re-enable allocation and verify cluster health.
Repeat for each node until all upgraded.
Cluster stays available during the process.

Full Transcript

Rolling upgrades in Elasticsearch mean upgrading nodes one by one to keep the cluster running without downtime. The process starts by disabling shard allocation to prevent shards from moving during the upgrade. Then, a node is stopped, upgraded, and restarted with the new version. After the node rejoins the cluster, shard allocation is re-enabled and cluster health is checked. This process repeats for each node until all nodes are upgraded. Cluster health may temporarily degrade but remains available throughout. This method avoids downtime and keeps data safe.