Blue-Green Upgrade to a New Cluster
When upgrading Elasticsearch itself (for example 7.x → 8.x), it’s safer to use two separate clusters.
Step 1 Create the New (Green) Cluster
Install the new version on new nodes.
Do not mix old and new nodes in the same cluster if the major version is different.
Step 2 Register a Snapshot Repository
On the blue cluster:
PUT _snapshot/backup_repo { "type": "fs", "settings": { "location": "/mnt/backup" } }
Step 3 Take a Snapshot
PUT _snapshot/backup_repo/snapshot_oct2025 { "indices": "my_index*", "ignore_unavailable": true, "include_global_state": false }
Step 4 Restore to the New Cluster
On the green cluster:
POST _snapshot/backup_repo/snapshot_oct2025/_restore { "indices": "my_index*", "rename_pattern": "my_index_v1", "rename_replacement": "my_index_v2" }
Now the green cluster has all data in the upgraded format.
Step 5 Validate and Switch
Point your load balancer or application connection to the new cluster endpoint.
If problems appear, simply point back to the old cluster (blue).
Continuous Sync with Cross-Cluster Replication (CCR)
If your dataset is very large or you cannot afford any delay between blue and green clusters,
Cross-Cluster Replication is the best approach.
CCR keeps a follower index in the new (green) cluster that automatically copies all operations from the leader index in the old (blue) cluster, including new documents, updates, and deletions, in near real-time.
How CCR Works
- Leader Cluster (Blue): keeps the original data
- Follower Cluster (Green): continuously replicates data
- You can later promote the follower cluster to production
CCR uses Elasticsearch’s internal replication engine to send new operations through the remote cluster connection.
Requirements for Cross-Cluster Replication
Requirement | Description |
---|---|
Elasticsearch Platinum or Enterprise license | CCR is a commercial feature (not in basic license) |
Both clusters on compatible versions | e.g., 8.5 → 8.10 (same major version) |
Remote connection configured | Green must know where to find Blue |
Security enabled | TLS/SSL + user roles for replication |
Index in Blue must have soft deletes enabled | Default in ES 7+ |
Check soft deletes setting:
GET my_index_v1/_settings
If missing:
PUT my_index_v1/_settings { "index.soft_deletes.enabled": true }
Setting Up CCR
Step 1 Register the Remote Cluster (on Green)
PUT _cluster/settings { "persistent": { "cluster.remote.blue_cluster.seeds": [ "blue-node1:9300" ] } }
Step 2 Create a Follower Index
PUT my_index_v2/_ccr/follow { "remote_cluster": "blue_cluster", "leader_index": "my_index_v1" }
Now, my_index_v2
will continuously follow all changes from my_index_v1
.
Step 3 Monitor Replication
GET my_index_v2/_ccr/stats
Check:
operations_read
→ how many operations replicatedtime_since_last_read_millis
→ lag timefollower_checkpoint
vsleader_checkpoint
Step 4 Promote the Follower (Switch to Green)
When ready to make Green the new production cluster:
- Pause replication:
POST my_index_v2/_ccr/unfollow
- Switch your application endpoint from Blue to Green.
- Optionally, start replicating back (if needed for rollback).
Now, Green is the active environment, Blue can be kept as a standby or backup.
CCR vs. Reindex/Snapshot
Method | Speed | Real-time | Cross-cluster | License |
---|---|---|---|---|
_reindex | Medium | No | Optional | Free |
Snapshot & Restore | Slow | No | Yes | Free |
CCR | Fast | Yes | Yes | Paid (Platinum/Enterprise) |
CCR is ideal for:
- Real-time migrations
- Large, high-volume clusters
- Zero-downtime cross-region setups