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 
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.dewrote:
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.