# What are the best practices around increasing the replica count drastically

**URL:** <https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936>\
**Category:** Elasticsearch\
**Created:** [February 26, 2020, 12:32am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936 "2020-02-26T00:32:14Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\
**Post date:** [February 26, 2020, 12:32am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/1 "2020-02-26T00:32:14Z")

</div>

I want to understand the implications of drastically increasing ReplicaCount eg:0-\>5 on Indexing requests.  
Since we have only 1 available copy, and the quorum has suddenly changed to 4 (n/2+1)  
the indexing requests are bound to fail.

What are the suggested way to increase the replica count such that minimum indexing requests fail?

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [February 26, 2020, 12:59am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/2 "2020-02-26T00:59:45Z")

</div>

Indexing does not use a quorum-based system. Increasing the number of replicas will not cause any indexing requests to fail.

---

<div class="post-metadata">

**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\
**Post date:** [February 26, 2020, 1:06am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/3 "2020-02-26T01:06:03Z")

</div>

I keep seeing message of the following type when indexing during a scaleup:

> ! org.elasticsearch.action.UnavailableShardsException: [indexname][0] Not enough active copies to meet write consistency of [ALL] (have 1, needed Quorum). Timeout: [1m], request: index  
> ! at

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [February 26, 2020, 5:34am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/4 "2020-02-26T05:34:18Z")

</div>

Which version of Elasticsearch are you using? If I recall correctly default write quorum kicks in once you reach 2 replicas, [at least on older versions](https://github.com/elastic/elasticsearch/issues/16728). If this is the case you may want to increase the replica count gradually.

It looks like this still [is tunable in current versions](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#index-wait-for-active-shards) but now defaults to not waiting for a quorum of replicas.

If you are on an old version suffering from this I would however also strongly recommend upgrading.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [February 26, 2020, 7:39am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/6 "2020-02-26T07:39:53Z")

</div>

I stand corrected 🙂 Since you didn't mention you were using a very old version I assumed you were asking about something recent. This message comes from a version that is well past the [end of its life](https://www.elastic.co/support/eol).

The simplest answer is probably to set write consistency to 1.

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [February 26, 2020, 8:02am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/7 "2020-02-26T08:02:16Z")

</div>

I wonder if the default might have been changed with the introduction of sequence numbers as it makes recovery faster?

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [February 26, 2020, 9:14am UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/8 "2020-02-26T09:14:58Z")

</div>

The notion of write consistency was [removed in 5.0.0](https://github.com/elastic/elasticsearch/pull/19454) as it doesn't really do what you might expect. IMO the [in-sync set mechanism](https://www.elastic.co/blog/tracking-in-sync-shard-copies) was really the feature that made it unnecessary, although the 6.x series further strengthened the guarantees in this area thanks to sequence numbers.

---

<div class="post-metadata">

**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\
**Post date:** [February 26, 2020, 7:54pm UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/9 "2020-02-26T19:54:58Z")

</div>

Thanks for the reply guys.  
So glad to hear that this is not the case with ES7. I'll start my experiments with ES7.

As per ES7 documentation, the writes are acknowledged as long as the primary is available(wait\_for\_active\_shards=1)

So when a Primary goes down after acknowledging some writes; how do we ensure that:

1. Stale replicas will not be promoted (since there is no concept of quorum)
2. Data loss doesn't occur.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [February 26, 2020, 8:04pm UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/10 "2020-02-26T20:04:03Z")

</div>

The [in-sync set mechanism](https://www.elastic.co/blog/tracking-in-sync-shard-copies) that I mentioned above is what makes sure we never promote a stale replica.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [March 25, 2020, 8:04pm UTC](https://discuss.elastic.co/t/what-are-the-best-practices-around-increasing-the-replica-count-drastically/220936/11 "2020-03-25T20:04:09Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
