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.

Practice

1.

What is the main purpose of setting replicas in an Elasticsearch index?

easy

A. To encrypt data for security

B. To delete old data automatically

C. To compress data for storage savings

D. To create copies of data for faster search and fault tolerance

Solution

1. Step 1: Understand replica role

   Replicas are copies of the original data that help improve search speed and provide backup in case of failure.

2. Step 2: Compare options

   Only To create copies of data for faster search and fault tolerance correctly describes replicas as copies for speed and safety; others describe unrelated features.

3. Final Answer:

   To create copies of data for faster search and fault tolerance -> Option D

4. Quick Check:

   Replicas = copies for speed and safety [OK]

Hint: Replicas are copies that speed up search and protect data [OK]

Common Mistakes:

• Confusing replicas with data deletion
• Thinking replicas compress data
• Assuming replicas encrypt data

2.

Which of the following is the correct syntax to update the number of replicas to 2 for an existing index named my_index using Elasticsearch REST API?

easy

A. POST /my_index/_settings { "number_of_replicas": 2 }

B. PUT /my_index/_settings { "number_of_replicas": 2 }

C. GET /my_index/_settings { "number_of_replicas": 2 }

D. DELETE /my_index/_settings { "number_of_replicas": 2 }

Solution

1. Step 1: Identify correct HTTP method for updating settings

   Elasticsearch uses PUT to update index settings like replicas.

2. Step 2: Match syntax with method

   PUT with the path /my_index/_settings and JSON body setting number_of_replicas to 2 is correct.

3. Final Answer:

   PUT /my_index/_settings { "number_of_replicas": 2 } -> Option B

4. Quick Check:

   Update settings uses PUT method [OK]

Hint: Use PUT to update index settings like replicas [OK]

Common Mistakes:

• Using POST instead of PUT for settings update
• Using GET which only retrieves settings
• Using DELETE which removes resources

3.

Given an index products with number_of_replicas set to 1, what will be the total number of shards (primary + replicas) if the index has 3 primary shards?

medium

A. 6

B. 4

C. 9

D. 3

Solution

1. Step 1: Understand shards and replicas

   Each primary shard has replicas equal to number_of_replicas. Total shards = primary shards + replicas.

2. Step 2: Calculate total shards

   3 primary shards + 1 replica each = 3 + 3 = 6 total shards.

3. Final Answer:

   6 -> Option A

4. Quick Check:

   Total shards = primary + replicas = 3 + 3 = 6 [OK]

Hint: Total shards = primary shards x (1 + replicas) [OK]

Common Mistakes:

• Counting only primary shards
• Adding replicas as 1 total instead of per shard
• Multiplying incorrectly

4.

What is wrong with this Elasticsearch index settings update request to set replicas to 3?

PUT /store/_settings
{
  "number_of_replicas": "3"
}

medium

A. The index name should be in quotes

B. PUT method cannot be used to update settings

C. The number_of_replicas value should be an integer, not a string

D. The JSON body is missing the settings wrapper

Solution

1. Step 1: Check data type of number_of_replicas

   number_of_replicas must be an integer, but here it is given as a string "3".

2. Step 2: Validate other parts

   PUT is correct method, index name does not require quotes in URL, and settings wrapper is optional in this context.

3. Final Answer:

   The number_of_replicas value should be an integer, not a string -> Option C

4. Quick Check:

   number_of_replicas must be integer [OK]

Hint: Use integer values for number_of_replicas, not strings [OK]

Common Mistakes:

• Putting number_of_replicas as a string
• Thinking PUT is wrong method
• Adding unnecessary JSON wrappers

5.

You want to increase the number of replicas for an index logs from 1 to 2 without downtime. Which approach is correct?

1. Update number_of_replicas setting to 2 using the REST API.
2. Reindex all data into a new index with 2 replicas.
3. Delete the index and recreate it with 2 replicas.
4. Change the number of primary shards to 2.

hard

A. Only step 1 is correct

B. Only step 2 is correct

C. Steps 1 and 2 are correct

D. Steps 3 and 4 are correct

Solution

1. Step 1: Understand replica update without downtime

   Elasticsearch allows changing number_of_replicas dynamically without downtime by updating settings.

2. Step 2: Evaluate other steps

   Reindexing or deleting index causes downtime; changing primary shards is unrelated to replicas.

3. Final Answer:

   Only step 1 is correct -> Option A

4. Quick Check:

   Update replicas via settings without downtime [OK]

Hint: Change replicas via settings update to avoid downtime [OK]

Common Mistakes:

• Thinking reindexing is needed to change replicas
• Deleting index causes data loss and downtime
• Confusing primary shards with replicas