# Are masters relevant when using external versioning?

**URL:** <https://discuss.elastic.co/t/are-masters-relevant-when-using-external-versioning/14491>\
**Category:** Elasticsearch\
**Created:** [November 20, 2013, 10:40am UTC](https://discuss.elastic.co/t/are-masters-relevant-when-using-external-versioning/14491 "2013-11-20T10:40:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tim\_S](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tim_s/32/958_2.png) [@Tim\_S](https://discuss.elastic.co/u/Tim_S)\
**Post date:** [November 20, 2013, 10:40am UTC](https://discuss.elastic.co/t/are-masters-relevant-when-using-external-versioning/14491/1 "2013-11-20T10:40:38Z")

</div>

Currently, it appears that version numbers are not always taken into  
account when resolving differences between nodes. It seems that the master  
takes priority. Is this by design? It seems that, in principle, if updates  
are being sent with external version numbers, it doesn’t matter about  
masters or split brains etc because you can always work out which version  
of a document is the correct one.

However, elasticsearch doesn’t keep a record of the version of deletes. So  
when resolving differences between nodes it doesn’t know if a node simply  
hasn’t received an update yet, or if it has actually deleted it since the  
most recent update.

It’s easy to try out:

1. Create an index with the default of 1 replica per primary shard,  
spread across two nodes, then shutdown both nodes.
2. Start node 1.
3. Send a document with external version 1.
4. Shutdown node 1.
5. Startup node 2.
6. Startup node 1.

In step 5 node 2 becomes the master, so when node 1 starts, node 1 removes  
the document you’ve just sent to it, because the master didn’t have it. If  
elasticsearch kept records of deletes, it would have known that the reason  
it didn’t exist on node 2 was because it hasn’t received it yet (rather  
than because it had deleted it).

And there’s a variation on the above which enables a delete to be ‘undone’,  
despite the fact that the version of the delete is greater than the version  
of the insert.

I feel like external versioning provides a way for elasticsearch to always  
know which version of a document is the most recent (whether it’s a delete  
or an update). So, I feel like I shouldn’t really have to worry about which  
order I start up my nodes.

So, I have two questions:

1. Am I wrong/right/crazy?
2. The current functionality of elasticsearch appears not to keep a  
persistent record of deletes and therefore can't use that record in  
resolving differences. Is there any reason why it couldn't? Are there any  
architectural reasons stopping the behaviour being changed?

Cheers,

Tim.

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<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:** [July 6, 2017, 2:06am UTC](https://discuss.elastic.co/t/are-masters-relevant-when-using-external-versioning/14491/2 "2017-07-06T02:06:00Z")

</div>

Closed on July 6, 2017, 2:06am UTC


