There are different things:
- replication type
- write consistency
- read consistency
By default, Elasticsearch indexing uses replication type "sync". The
parameter is "action.replication_type". This ensures the execution of
replication actions across all participating nodes (replicated shards)
before indexing operation returns. An alternative is "async", which starts
replication actions in separate threads and does not wait for answers from
the nodes. See https://github.com/elasticsearch/elasticsearch/issues/196
There is also a write consistency level, which controls the success of the
write executions in a distributed system. The parameter is
"action.write_consistency". By default, it is set to "quorum". Write
consistency may be given even if not all writes to all shard have
succeeded, for example if at least half of the replica level is met. If
such a quorum is not fulfilled, indexing returns with an error after a
timeout. Other values are "one" or "all".
The write consistency across node failure situations is ensured with a
"transaction log" or translog in write-ahead style, where on each node all
write operations are registered in a separate file before they got executed
at shard level.
Note, read consistency is different. For doing read consistency, each
Lucene index reader would have to reopen the index to get the most current
index state, which is an expensive operation. Lucene offers "near real
time" search (NRT) to improve the situation. This works by using the
IndexWriter buffer as an additional segment in search operations.
Elasticsearch makes use of it by default. The parameter
"action.get.realtime" is set to true by default. This means, you won't have
to refresh the index in order to use a "get" when you want to read what you
To let all other readers read what you have written, the Elasticsearch
buffers for an index refresh regularly, and all readers on that index will
obtain the current state. The parameter is "index.refresh_interval". By
default, the interval is "1s" (one second).
To guarantee read consistency, you must refresh the Elasticsearch index
with the parameter "refresh".
Another method would be blocking all reads until the next refresh has
happened. Bad for performance, good for transactional-style loving DB
folks. An issue is open for this