On Thu, Jun 12, 2014 at 8:52 PM, shikhar <[email protected]> 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 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 succeded on the primary shard as well as all replicas (as per the same cluster state as the check is performed on). In case it fails on some replica(s), the operation would be retried (together with the write-consistency-level check using a possibly-updated cluster state). > This makes it unsuitable for a primary data store, given you can see data > loss despite having replicas! If using ES as a primary store, you should really be running it with * index.gateway.local.sync: 0* to make sure the translog fsync's on every write operation ........ A follow-up question: what if there is a failure on one of the replicas that prevents writes (e.g. disk full) but this is not preventing the node from dropping out of discovery state due to being healthy otherwise? Does it not make that node a SPOF? This is something we have run into with SolrCloud <https://issues.apache.org/jira/browse/SOLR-5805>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHWG4DOi0sTu5_mwv%3DNJL5SH7%3D1Z5CG2iULSbF0_P7ZDULY-qw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
