As your business grows, you may need to scale out or in, upgrade versions, or migrate nodes in your Elasticsearch cluster. To support these operations, Elasticsearch provides two cluster update methods: in-place update and blue-green update. In most cases, the system automatically selects the appropriate method. When you restart a cluster or node, or upgrade a cluster's configuration, you can manually select a method.
Before you begin
Before any cluster update, make sure that:
Each index in the cluster has at least one replica shard. This improves cluster stability.
For multi-zone clusters: the number of replica shards per index is less than the number of zones the cluster is deployed in. After the change, you can manually increase the number of replica shards. For more information, see Index Templates.
How each method works
In-place update
The system performs a rolling update on the nodes you want to update. No data migration is involved, so update time is not affected by data volume. Cluster performance may be temporarily affected during the update.
Best for: Clusters that hit a performance bottleneck where completing the update quickly is the priority.
In-place updates may affect cluster performance. Schedule them during off-peak hours.
Blue-green update
The system adds the same number of new nodes to the cluster, migrates data from the original nodes to the new nodes, then removes the original nodes. The migration is seamless but time-consuming. Node IP addresses change after the update completes.
Best for:
Cluster availability is the priority and update speed is not critical.
A node has persistent performance issues, such as sustained high CPU utilization.
Blue-green update duration depends on cluster specifications, data structure, and data volume — typically a few hours. In extreme cases, read operations may be affected. Configure an access retry mechanism for your client before starting a blue-green update. Schedule blue-green updates during off-peak hours.
Choose an update method
The following table shows when each method applies.
When blue-green update is required
Some operations can only use the blue-green update method:
| Scenario | Notes |
|---|---|
| Migrating nodes across zones | Blue-green update is the only available method. |
| Changing the disk type of nodes during an upgrade or downgrade | Blue-green update is the only available method, even if you can otherwise choose a method for the upgrade. |
| Changing ultra disk storage space to more than 2 TB during an upgrade | Blue-green update is the only available method. |
When blue-green update is unavailable
The following operations cannot use the blue-green update method:
| Scenario | Available method |
|---|---|
| Forced restart | In-place update only |
| Blue-green update only for dedicated master nodes | Not supported |
| Blue-green update only for client nodes (when the cluster has no dedicated master nodes) | Not supported |
General guidance
| Scenario | Recommended method |
|---|---|
| Cluster hits a performance bottleneck; fastest update needed | In-place update |
| High availability is the priority; update speed is not critical | Blue-green update |
| Node performance is consistently degraded (e.g., high CPU utilization) | Blue-green update |
What's next
To manually select an update method when restarting, see Restart a cluster or node.
To manually select an update method when upgrading configuration, see Upgrade the configuration of a cluster.