Question on read consistency

Elastic Stack Elasticsearch
10

When all shards are not allocated, then with quorum (default), a minimum amount of shard must be allocated.

If true, all allocated shards will get the document before the operation is considered as successful.

When some shards are missing, when they will be allocated, they will first have to be synchronized before accepting any request. So a shard which is not fully started won't be hit by your GET request.

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 4 nov. 2013 à 20:07, Amit Soni amitsoni29@gmail.com a écrit :

Hi David - Thanks for explaining it and my apology if there is something obvious that I am missing.

If set to all, that means all shards must be allocated on the cluster to accept the index operation.
Totally understand that if set to all, then all shards would get the document (either in transaction log or index) and then my 'GET' operation is guaranteed to fetch the updated copy.

However when the setting is for 'quorum', how is it guaranteed that my GET will get the updated copy even when the request is routed to a shard which didn't form the quorum.

-Amit.

On Mon, Nov 4, 2013 at 10:13 AM, David Pilato david@pilato.fr wrote:

It basically checks that you have at least enough shards to replicate to. If not, operation will fail.

If set to all, that means all shards must be allocated on the cluster to accept the index operation.

Makes sense?

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 4 nov. 2013 à 18:49, Amit Soni amitsoni29@gmail.com a écrit :

Hi Alex - If the indexing happens into all the shards then I am not sure of the role of 'write consistency' configuration. For instance if I continue to have write consistency set to quorum, writing to all the available shards would be expensive, isn't?
I am not sure I understand why the write would happen to ALL the shards if the write consistency is set to 'quorum'.

-Amit.

On Mon, Nov 4, 2013 at 12:51 AM, Alexander Reelsen alr@spinscale.de wrote:

Hey,

I think the write consistency parameter just checks for availability of shards (in order to make the operation to be allowed), but indexing (unless replication is configured async) still needs to happen into all shards. So the realtime GET is independent from the number of shards.

--Alex

On Sun, Nov 3, 2013 at 9:46 AM, joergprante@gmail.com joergprante@gmail.com wrote:

Write consistency in ES is not directly connected to read, it is just that indexing a document returns early with default quorum consistency and you can't be sure this document has been indexed on all replica shards.

The translog is per shard, so if a GET request goes to a different shard, you can't be sure about realtime get.

You have several options with default quorum: use refresh (which is expensive), or use no replica while indexing, or use preference on primary shard while read, since the primary shard is the first one written to.

Jörg

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.