# GET Consistency (and Quorum) in ElasticSearch **URL:** \ **Category:** Elasticsearch\ **Created:** [December 29, 2012, 10:40am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201 "2012-12-29T10:40:08Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![vaidik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vaidik/32/1134_2.png) [@vaidik](https://discuss.elastic.co/u/vaidik)\ **Post date:** [December 29, 2012, 10:40am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201/1 "2012-12-29T10:40:08Z")
I am new to ElasticSearch and I am evaluating it for a project. In ES, Replication can be sync or async. In case of async, the client is returned success as soon as the document is written to the primary shard. And then the document is pushed to other replicas asynchronously. When written asynchronously, how do we ensure that when GET is done, document is returned even if it has not propagated to all the replicas (just in case we do a GET immediately after PUTing the document). Because when we do a GET in ES, the query is forwarded to one of the replicas of the appropriate shard. Provided we are writing asynchronously, the primary shard may have the document but the selected replica for doing the GET may not have received/written the document yet. In Cassandra, we can specify consistency levels (ONE, QUORUM, ALL) at the time of writes as well as reads. Is something like that possible for reads in ES? -- ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [December 29, 2012, 11:04am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201/2 "2012-12-29T11:04:11Z")
As far as I understand the big picture, when you index a document it's written in the transaction log and then you get a succesful answer from ES. After, in an asynchronous manner, it's replicated on other nodes and indexed by Lucene. That said, you can not _search_ immediatly for the document, but you can _GET_ it. ES will read the tlog if needed when you GET a document. I think (not sure) that if the replica is not up to date, the GET will be sent on the primary tlog. Correct me if I'm wrong. -- David 😉 Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs Le 29 déc. 2012 à 11:40, Vaidik Kapoor [kapoor.vaidik@gmail.com](mailto:kapoor.vaidik@gmail.com) a écrit : I am new to ElasticSearch and I am evaluating it for a project. In ES, Replication can be sync or async. In case of async, the client is returned success as soon as the document is written to the primary shard. And then the document is pushed to other replicas asynchronously. When written asynchronously, how do we ensure that when GET is done, document is returned even if it has not propagated to all the replicas (just in case we do a GET immediately after PUTing the document). Because when we do a GET in ES, the query is forwarded to one of the replicas of the appropriate shard. Provided we are writing asynchronously, the primary shard may have the document but the selected replica for doing the GET may not have received/written the document yet. In Cassandra, we can specify consistency levels (ONE, QUORUM, ALL) at the time of writes as well as reads. Is something like that possible for reads in ES? -- -- ---
**Author:** ![karmi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/karmi/32/44951_2.png) [@karmi](https://discuss.elastic.co/u/karmi)\ **Post date:** [December 30, 2012, 9:48am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201/3 "2012-12-30T09:48:42Z")
> Provided we are writing asynchronously, the primary shard may have the > document but the selected replica for doing the GET may not have > received/written the document yet. You can specify the "preference" in the Get API, see [http://www.elasticsearch.org/guide/reference/api/get.html](http://www.elasticsearch.org/guide/reference/api/get.html) > In Cassandra, we can specify consistency levels (ONE, QUORUM, ALL) at the > time of writes as well as reads. Is something like that possible for reads > in ES? You can specify the "write consistency" in a similar way with Elasticsearch, see [http://www.elasticsearch.org/guide/reference/api/index\_.html](http://www.elasticsearch.org/guide/reference/api/index_.html) Karel -- ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 30, 2012, 11:50am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201/4 "2012-12-30T11:50:45Z")
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](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". See [https://github.com/elasticsearch/elasticsearch/issues/444](https://github.com/elasticsearch/elasticsearch/issues/444) 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 write. 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 > Jörg -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:58am UTC](https://discuss.elastic.co/t/get-consistency-and-quorum-in-elasticsearch/10201/5 "2017-07-06T02:58:11Z")