High replica count on warm nodes
Some indices on warm nodes have a higher replica count than the configured threshold. Extra replicas duplicate every primary shard and still consume disk and background resources on warm nodes even when traffic is lower than on the hot tier.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Low |
| Scope | Node |
| Domains | replication, resource-utilization |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
2 replicas on warm nodes for these indices: logs-prod-000045, logs-prod-000046.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Reduce replicas to one
Condition: Shown when replication factor exceeds warm tier threshold.
Set number_of_replicas to 1 for logs-prod-000045 (currently 2 replicas) on the warm tier with the action below. Fewer replicas can increase search latency because fewer nodes serve reads.
PUT logs-prod-000045/_settings
{
"index": {
"number_of_replicas": 1
}
}
Requires the manage index privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Each replica is a full copy of a primary shard. Higher replica counts improve availability and search capacity, but they also multiply disk use and write amplification: every index, update, and recovery must reach every replica.
On the warm tier, which usually holds older or less active data, more replicas than you need for fault tolerance still occupy storage and background capacity. If the replica count stays high without a matching availability requirement, warm-tier cost and node pressure tend to rise without improving hot-tier performance.