Implementing Zero-Downtime Deployments for Elasticsearch

To update Elasticsearch without downtime, run a rolling upgrade: replace one node at a time, upgrading data nodes tier by tier and master-eligible nodes last, and wait for the cluster to return to green before moving on. As long as every index has at least one replica, searches and writes keep flowing while each node restarts.

What is a rolling deployment?

A rolling deployment updates your Elasticsearch cluster one node at a time, so the rest of the cluster keeps serving traffic while each node is out.

What do you need before you start?

Before implementing rolling deployments:

• Ensure the cluster has multiple nodes
• Configure replicas so every shard has a copy on another node
• Set up monitoring and alerting
• Take a snapshot and have a rollback plan ready
• Check your upgrade path: moving to 9.x means first upgrading to the latest 8.19 release, and indices created before 8.x must be reindexed, deleted or archived first (the Upgrade Assistant in 8.19 helps with this)

How do you run a rolling upgrade, step by step?

1. (Optional) Limit shard allocation

Elastic's current upgrade guide marks this step optional. Restricting allocation to primaries stops the cluster from rebuilding replicas elsewhere while a node is briefly offline:

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}'

2. (Optional) Stop non-essential indexing and flush

Temporarily pause non-critical indexing to reduce load, and flush so shard recovery is faster when the node comes back. If you run machine learning jobs, pause them too.

3. Update nodes one by one, in the right order

Upgrade data nodes first, one tier at a time (frozen, then cold, warm, hot, then any other data nodes such as content), then other non-master nodes (ingest, ML, coordinating), and master-eligible nodes last.

For each node:

1. Stop the Elasticsearch service
2. Install the new version and merge your configuration (don't set cluster.initial_master_nodes on an existing cluster)
3. Upgrade any plugins on that node
4. Start the service and wait for the node to rejoin the cluster
5. Re-enable allocation if you limited it, and wait for green health before the next node

4. Re-enable shard allocation

curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}'

How do data tiers help with deployments?

Elasticsearch groups data nodes into data tiers with dedicated node roles, which replace the older hand-rolled "hot-warm" setups built on custom node attributes:

• Hot (data_hot): Active indexing and recent, frequently searched data
• Warm (data_warm): Less frequently queried data
• Cold (data_cold): Infrequently accessed data, optimized for storage cost
• Frozen (data_frozen): Rarely queried data, stored as partially mounted searchable snapshots
• Content (data_content): Non-time-series data such as product catalogs

Tiers give the upgrade a natural order and let you upgrade the least critical nodes first.

What should you monitor during a deployment?

Key metrics to monitor:

• Cluster health status
• Node availability
• Query response times
• Indexing throughput
• Memory and CPU usage

Best practices

1. Test in staging first: Always validate deployment procedures in a non-production environment
2. Automate the process: Use configuration management tools
3. Monitor continuously: Set up real-time monitoring and alerting
4. Have a rollback plan: Prepare for quick recovery if issues arise
5. Document procedures: Maintain clear deployment documentation

Conclusion

Zero-downtime deployments are achievable with proper planning and execution. By following these practices, you can maintain high availability while keeping your Elasticsearch cluster up to date.

Sources

• Elastic documentation, Upgrade Elasticsearch (rolling upgrade)
• Elastic documentation, Plan your upgrade
• Elastic documentation, Data tiers
• Elastic documentation, Cluster-level shard allocation and routing settings