Replica management in Elasticsearch - Step-by-Step Execution

Concept Flow - Replica management

Create Index

↓

Set Number of Replicas

↓

Index Data

↓

Elasticsearch Copies Data to Replicas

↓

Search Queries Use Primary or Replica

↓

If Node Fails, Replicas Promote to Primary

This flow shows how Elasticsearch manages replicas: creating an index, setting replicas, indexing data, copying to replicas, using replicas for search, and handling node failures.

Execution Sample

Elasticsearch

PUT /my_index
{
  "settings": {
    "number_of_replicas": 1
  }
}

This code creates an index named 'my_index' with 1 replica shard.

Execution Table

Step	Action	Primary Shard State	Replica Shard State	Result
1	Create index with 1 replica	Initialized	Initialized but empty	Index created with 1 primary and 1 replica shard
2	Index document into primary	Document stored	Replica empty	Data stored on primary only
3	Elasticsearch copies data to replica	Document stored	Document copied	Replica now has same data
4	Search query sent	Primary or Replica used	Primary or Replica used	Search results returned from any shard
5	Primary node fails	Unavailable	Replica promoted to primary	Cluster recovers with replica as new primary
6	Add new replica	Primary active	New replica initializing	Replica shard created and syncing
7	Replica sync complete	Primary active	Replica synced	Replica ready for queries

💡 Execution stops after replica sync completes and cluster is stable

Variable Tracker

Shard	Start	After Step 2	After Step 3	After Step 5	Final
Primary Shard	Initialized	Document stored	Document stored	Unavailable (failed)	Recovered (promoted replica)
Replica Shard	Initialized but empty	Empty	Document copied	Promoted to primary	Synced and active

Key Moments - 3 Insights

Why is data first stored only on the primary shard before copying to replicas?

Because Elasticsearch writes data to the primary shard first to ensure consistency, then asynchronously copies it to replicas as shown in step 2 and 3 of the execution_table.

What happens to replicas when the primary shard's node fails?

As shown in step 5, a replica shard is promoted to primary to keep the cluster available without data loss.

Can search queries use replica shards?

Yes, step 4 shows that search queries can be served by either primary or replica shards to balance load.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the replica first get the document data?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Replica Shard State' column in execution_table rows for step 3

According to variable_tracker, what is the state of the primary shard after step 5?

A Document stored

B Recovered (promoted replica)

C Unavailable (failed)

D Initialized

💡 Hint

Look at the 'Primary Shard' row under 'After Step 5' in variable_tracker

If the number_of_replicas is set to 2 instead of 1, how would the execution_table change?

A Search queries would only use primary shards

B There would be two replica shard states tracked and synced

C Primary shard would store twice the data

D Replica shards would not be created

💡 Hint

Think about how replicas are managed and synced as shown in the execution_table and variable_tracker

Concept Snapshot

Replica management in Elasticsearch:
- Create index with 'number_of_replicas' setting
- Data writes go to primary shard first
- Data asynchronously copied to replica shards
- Search queries can use primary or replicas
- If primary fails, replica promoted to primary
- Replicas improve availability and search performance

Full Transcript

Replica management in Elasticsearch involves creating an index with a specified number of replicas. When data is indexed, it is first stored on the primary shard. Then Elasticsearch copies this data to replica shards asynchronously. Search queries can be served by either primary or replica shards to balance load. If the primary shard's node fails, a replica shard is promoted to primary to maintain availability. This process ensures data redundancy and fault tolerance in the cluster.