On Fri, Jun 13, 2014 at 12:11 PM, shikhar shik...@schmizz.net wrote:
I take this back, I understand the ES model better now. So although the
write-consistency-level check is only applied before the write is about
to be issued, with sync replication the client can only get an ack if it
index.gateway.local.sync: 0 is related to durability, it means, the
underlying data is really going to disk by using the guarantee of
FileChannel.force(false). This destroys performance compared to the default
value of ES, because there are a lot more I/O operations on OS layer when
fsync() is
On Thu, Jun 12, 2014 at 8:52 PM, shikhar shik...@schmizz.net wrote:
ES currently does not seem to provide any guarantee that an acknowledged
write (from the caller's perspective) succeeded on a quorum of replicas.
I take this back, I understand the ES model better now. So although the
Hi Anand,
I would love to know as well, and asked in this thread today: quorum write
+ sync replication: guarantees.
It is pretty important information given ElasticSearch is being touted as a
reliable data store... which the presence of a write consistency level
setting would tempt one to
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
On Thu, Jun 12, 2014 at 8:42 PM, joergpra...@gmail.com
joergpra...@gmail.com wrote:
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
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 (
