High replica count on content nodes
Some indices on content nodes have a higher replica count than the configured threshold. Extra replicas duplicate every primary shard and add CPU, memory, and disk work across content nodes that hold those copies.
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 content 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 content tier threshold.
Set number_of_replicas to 1 for logs-prod-000045 (currently 2 replicas) on the hot 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 content nodes, which typically hold general-purpose indices, more replicas than you need for fault tolerance consume capacity that could serve other workloads. If the replica count stays high without a matching availability requirement, storage cost and indexing latency on content nodes tend to rise first.