Primary and Replica Shard Sync


(Imran Siddique) #1

Let us take a sample scenario in Azure Elasticsearch setup where we have below shard, node, index allocation mapping something like below –

During planned Azure update, here is the list of things which will happen –

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?

(Imran Siddique) #2

Ping.


(Christian Dahlqvist) #3

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.


(Imran Siddique) #4

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.


(Christian Dahlqvist) #5

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 of shards to be available.


(Imran Siddique) #6

In this case, the replica count is 1... So quorum is 1 and not 2.. If primary is available, indexing will succeed.

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.


(Christian Dahlqvist) #7

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.


(Imran Siddique) #8

agreed. I would like to know how ES resolves the data inconsistency between shards in this case


(Christian Dahlqvist) #9

Elasticsearch will take one of the shards, so any data written only to the other will be lost.


(Imran Siddique) #10

Thanks @Christian_Dahlqvist !


(Mark Walkom) #11

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.


(Imran Siddique) #12

Point noted. Thanks.


(system) #13