# Why not reconcile shards/docs after split brain recovery?

**URL:** <https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333>\
**Category:** Elasticsearch\
**Created:** [March 21, 2017, 1:28am UTC](https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333 "2017-03-21T01:28:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Larry\_Durden](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@Larry\_Durden](https://discuss.elastic.co/u/Larry_Durden)\
**Post date:** [March 21, 2017, 1:28am UTC](https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333/1 "2017-03-21T01:28:38Z")

</div>

Yes split brains are bad and we can avoid it by setting discovery.zen.minimum\_master\_nodes to (n/2+1) quorums. This question is to understand why Elasticsearch cannot attempt to reconcile/replay the diverged data when a cluster recovers back from split brain.

Yes, in case some documents have conflicting data, I understand there is data corruption but in many scenarios where documents on either halves have no conflicts, does Elasticsearch attempt to merge and reconcile the shards on the diverged halves?

If not that would be a cool feature to add but I am guessing this is not possible today. So I would love to understand more on what exactly happens when the cluster is coming out of a split brain and if I am right, why does Elasticsearch currently just discard all state from the half that was restarted (to join the other half)

---

<div class="post-metadata">

**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:** [March 21, 2017, 8:26am UTC](https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333/2 "2017-03-21T08:26:25Z")

</div>

How do you determine which documents take precedence?  
How do you inform the user that they system is discarding data in favour of another?

---

<div class="post-metadata">

**Author:** ![Larry\_Durden](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@Larry\_Durden](https://discuss.elastic.co/u/Larry_Durden)\
**Post date:** [March 22, 2017, 6:17pm UTC](https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333/3 "2017-03-22T18:17:49Z")

</div>

In conflicting scenarios, I agree - you dont resolve conflicts and keep behavior as is (there is data loss here so i would even prefer calling this red when reconcilation attempt failed)

In non conflicting scenarios, which will be plenty does Elasticsearch try to automatically merge the diverged shards?

- Example 1 - versioned docs where versioning is provided externally)
- Example 2 - append only logstash/beat based log files which are append only and different log entries went to different halves

---

<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:** [April 19, 2017, 6:18pm UTC](https://discuss.elastic.co/t/why-not-reconcile-shards-docs-after-split-brain-recovery/79333/4 "2017-04-19T18:18:00Z")

</div>

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