I think the documentation is quite clear, but I try to explain in my own words.
1.1 Not sure what you mean "after the quorum check". Write consistency is a model where ES makes sure there are enough recipients (nodes) before writes are executed. consistency=quorum fails if you have too few nodes to match the actual replica count of the index. 1.2. No new shard is created - not sure I understand why such a thing should happen? 2.1. No, the operation fails early if replica count is too low. replication=async means, the operation is executed without waiting for nodes to respond. It does not mean to ignore replica count. 2.2. When a node comes back, index recovery is performed to obtain consistency. The node holding a replica with intact checksums and youngest translog "wins" and will send this version of the shard to the other node. Jörg On Fri, Apr 4, 2014 at 8:36 PM, Anand Somani <meatfor...@gmail.com> wrote: > Hi, > > We are trying to use ES as a system of record, so I trying to understand > its consistency and durability related guarantees and knobs. > > For this scenario assume I will have a 2 copies ( 1 replica). From what I > have read and gleaned ( > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-consistency) > => > > - write.consistency is a check to see if the operation can be > executed. It offers no guarantees in terms of data durability or operation > guarantee > - replication type => Is this for durability guarantees? > - sync all copies of the data are saved/indexed on nodes before it > returns. > - async primary node will be synchronous the others will be async. > > Failure scenario question > > Scenario is > > => PUT with write.consistency=quorum, but different replications = > sync/async. > => What happens if there is a network glitch after the quorum check > succeeds, such that one of the non-primary shard machines is not reachable > or down? > > > 1. Put with write.consistency=quorum and replication=sync => > 1. Would the operation fail from the callers perspective? Seems > like it would after some retries? > 2. I have read that if the primary succeeds, and if it has problems > with replica then it will try to create a new shard, is that correct > understanding? I assume that should be preventable to handle network > failures/partitions? > 2. Put with write.consistency=quorum and replication=async => > 1. The operation succeeds, since primary shard is up. > 2. Now in sometime the unreachable node is back, how does it get > that copy of data that it did not get, is there some steps/process that > will do that automatically? > > > If these have been asked/answered or documents, please point me to a > source and my apologies. > > > Thanks > Anand > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CANN9sNpFY39T2t2uy51Zh0m1p%3DBpqtqb7f9ho1iWTV%3DeUab23Q%40mail.gmail.com > <https://groups.google.com/d/msgid/elasticsearch/CANN9sNpFY39T2t2uy51Zh0m1p%3DBpqtqb7f9ho1iWTV%3DeUab23Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG2SqYCjnq7WO5BCJZdPXtVDKbmcuwLB0WQU5Djcvd-rg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
