A replica is a duplicate of a primary shard, placed on a different node. It keeps another copy of shard data for redundancy and high availability, and it can answer read requests. An index may have one or more replicas per primary shard; running with none is possible but discouraged for production. section 3.2.2 section 3.2.4
A search index that needs a backup
Create a chats index with one primary shard and one replica: PUT chats { "settings": { "number_of_shards": 1, "number_of_replicas": 1 } } On a single-node cluster, Elasticsearch creates the primary but does not place its replica on that same node. The result is YELLOW health because the replica is unassigned. Add a node on another machine in the same cluster to give the replica somewhere safe to run. section 14.1.1 section 14.1.2
Replica placement matters: a primary and its replica must not share a node, because one node failure would otherwise remove both copies. When nodes join or leave, shard and replica allocation changes; a lost replica may be promoted to a primary after a node crash. section 3.2.4 section 3.2.5
Increase read capacity without rebuilding the index
For a read-heavy application, raise the replica count on a live index: PUT chats/_settings { "number_of_replicas": 10 } Extra replicas are exact shard copies. Elasticsearch can route queries to them while primary shards handle indexing, increasing read throughput. Plan capacity first: every replica requires storage and memory comparable to its primary shard. section 14.1.3 section 14.3.1
Use replicas with these operational expectations:
- Treat a YELLOW single-node cluster as a missing-replica condition, not as a production-ready backup arrangement. section 14.1.2
- Use the cluster allocation explanation API to confirm why a replica is unassigned; the same_shard decider prevents a second copy on the node already holding that shard. section 14.1.2
- Scale replica count for read demand, but size nodes for the additional copies and operational overhead. section 14.1.3 section 14.3.1
Listing 14.3 Increasing the replica count on a live index
PUT chats/_settings
{
"number_of_replicas": 10
}
The live-index settings request provides a focused pattern for adding replicas when read-query load becomes a bottleneck. section 14.1.3
