# Primary and Replica Shard Sync **URL:** \ **Category:** Elasticsearch\ **Created:** [February 2, 2016, 11:57am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721 "2016-02-02T11:57:25Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 2, 2016, 11:57am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/1 "2016-02-02T11:57:25Z")
Let us take a sample scenario in Azure Elasticsearch setup where we have below shard, node, index allocation mapping something like below – ![](https://us1.discourse-cdn.com/elastic/original/2X/8/88d08caccd28be5aad3666063ef4f45bf2ce3323.PNG) During planned Azure update, here is the list of things which will happen – ![](https://us1.discourse-cdn.com/elastic/original/2X/d/dee471a9871607544323ff6d96795ca4fa8a0a5d.PNG) Couple of Qs - 1. Will M2's shards' updated contents (when M1 was down) will be synced to M1's shard? 2. Will M1's shards' updated contents (when M2 was down) will be synced to M2's shard? ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 3, 2016, 3:49am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/2 "2016-02-03T03:49:07Z")
Ping. ---
**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 3, 2016, 7:20am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/3 "2016-02-03T07:20:28Z")
If you only have two nodes in your cluster and both are master eligible, you should have minimum\_master\_nodes set to 2. This means that when the first node goes down, Elasticsearch would stop accepting indexing requests as no master can be elected. The primary and the replica should therefore have the same data. If you on the other hand had 3 (or more) nodes in the cluster, it would be possible to elect a master after the first node went offline and Elasticsearch will then relocate the missing shard to a node that does not already contain it. It can then continue taking writes. ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 3, 2016, 7:57am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/4 "2016-02-03T07:57:16Z")
Thanks @Christian_Dahlqvist I intentionally didn't talk about master nodes... Assume these are just 2 data nodes in the ES cluster and master/client nodes are different ones. ---
**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 3, 2016, 8:11am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/5 "2016-02-03T08:11:38Z")
Assuming you only have 2 data nodes and separate dedicated master nodes so that a master is available at all times, I believe Elsticsearch still will not accept the write while one doc the data nodes is down as it requires a [quorum](https://www.elastic.co/guide/en/elasticsearch/guide/master/distrib-write.html) of shards to be available. ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 3, 2016, 8:24am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/6 "2016-02-03T08:24:52Z")
In this case, the replica count is 1... So quorum is 1 and not 2.. If primary is available, indexing will succeed. > **[Index API | Elasticsearch Guide \[8.11\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-index_.html#index-consistency)** > Note, for the case where the number of replicas is 1 (total of 2 copies of the data), then the default behavior is to succeed if 1 copy (the primary) can perform the write. ---
**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 3, 2016, 11:11am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/7 "2016-02-03T11:11:46Z")
If that is the case you would probably run the risk of losing some data if you do not let the cluster settle into a green state before taking the next data node down. ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 3, 2016, 11:31am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/8 "2016-02-03T11:31:54Z")
agreed. I would like to know how ES resolves the data inconsistency between shards in this case ---
**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 3, 2016, 11:46am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/9 "2016-02-03T11:46:20Z")
Elasticsearch will take one of the shards, so any data written only to the other will be lost. ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 3, 2016, 12:26pm UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/10 "2016-02-03T12:26:45Z")
Thanks @Christian_Dahlqvist ! ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [February 3, 2016, 10:53pm UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/11 "2016-02-03T22:53:04Z")
> [@mosiddi](#): > > Ping FYI we are all volunteers here, even those that work for Elastic. If you want SLA based response times then you should look at a Subscription with Elastic. Otherwise, please be patient and respect your fellow community members. ---
**Author:** ![mosiddi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mosiddi/32/577_2.png) [@mosiddi](https://discuss.elastic.co/u/mosiddi)\ **Post date:** [February 4, 2016, 3:36am UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/12 "2016-02-04T03:36:20Z")
> [@warkolm](#): > > I we are all volunteers here, even those that work for Elastic. If you want SLA based response times then you should look at a Subscription with Elastic. Point noted. Thanks. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 11:19pm UTC](https://discuss.elastic.co/t/primary-and-replica-shard-sync/40721/13 "2017-07-05T23:19:04Z")