Why Replica management in Elasticsearch? - Purpose & Use Cases

The Big Idea

What if your website never went down, even when servers crash?

The Scenario

Imagine you run a busy online store. Your product data is stored in one single place. If that place goes down, your customers can't see products or buy anything.

You try to keep backups manually, copying data to other servers yourself.

The Problem

Manually copying data is slow and easy to forget. If the main server crashes suddenly, your backup might be outdated or missing. Customers get frustrated when the site is slow or unavailable.

The Solution

Replica management automatically keeps copies of your data on other servers. If one server fails, Elasticsearch quickly switches to a replica without losing data or downtime.

This means your store stays online and fast, even if something breaks.

Before vs After

✗ Before

curl -XPOST 'server1:9200/_snapshot/my_backup' -H 'Content-Type: application/json' -d '{"indices": "products"}'
curl -XPOST 'server2:9200/_snapshot/my_backup/_restore' -H 'Content-Type: application/json'

✓ After

PUT /products/_settings
{
  "number_of_replicas": 2
}

What It Enables

Replica management makes your data safe and your service reliable, so users always get fast access without interruptions.

Real Life Example

An online store uses replica management to keep product listings available even during server failures, ensuring customers can shop anytime without delays.

Key Takeaways

Manual backups are slow and risky.

Replica management automates data copies across servers.

This keeps your service fast and reliable, even if a server fails.

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