# Read/Write consistency

**URL:** https://discuss.elastic.co/t/read-write-consistency/17246
**Category:** Elasticsearch
**Created:** [April 28, 2014, 11:57pm UTC](https://discuss.elastic.co/t/read-write-consistency/17246 "2014-04-28T23:57:06Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![Mohit\_Anchlia](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@Mohit\_Anchlia](https://discuss.elastic.co/u/Mohit_Anchlia)
#### Post date: [April 28, 2014, 11:57pm UTC](https://discuss.elastic.co/t/read-write-consistency/17246/1 "2014-04-28T23:57:06Z")

</div>

Trying to understand the following scenarios of consistency in  
elasticsearch:

1. sync replication - How does elasticsearch deals with consistency issue  
that may arise from 1 node momentarily going down and missing writes to it?  
When the node comes backup and the reads going to the non-primary shards  
could get inconsistent data?
2. async replication - What happens if replication is slow for some reason,  
could users see inconsistent data?
3. sync/async replication - how does elasticsearch keep data in sync for  
those writes that never happened on the non-primary shard because of  
network/node failures?

--  
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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWrpUEpVU2yg3km\_v%3DtuA0duSiFV5HYnPyeCztdmrTcMsA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWrpUEpVU2yg3km_v%3DtuA0duSiFV5HYnPyeCztdmrTcMsA%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### Author: ![Mohit\_Anchlia](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@Mohit\_Anchlia](https://discuss.elastic.co/u/Mohit_Anchlia)
#### Post date: [April 29, 2014, 4:28pm UTC](https://discuss.elastic.co/t/read-write-consistency/17246/2 "2014-04-29T16:28:43Z")

</div>

Could somebody help get some insights on this topic?

On Mon, Apr 28, 2014 at 4:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:

> Trying to understand the following scenarios of consistency in  
> elasticsearch:
> 
> 1. sync replication - How does elasticsearch deals with consistency issue  
> that may arise from 1 node momentarily going down and missing writes to it?  
> When the node comes backup and the reads going to the non-primary shards  
> could get inconsistent data?
> 2. async replication - What happens if replication is slow for some  
> reason, could users see inconsistent data?
> 3. sync/async replication - how does elasticsearch keep data in sync for  
> those writes that never happened on the non-primary shard because of  
> network/node failures?

--  
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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWrv\_zkCQ26dk9Ey41zckaix9QZWP6ObUx4dsYp0p99Bgg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWrv_zkCQ26dk9Ey41zckaix9QZWP6ObUx4dsYp0p99Bgg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### Author: ![radu\_gheorghe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe/32/556_2.png) [@radu\_gheorghe](https://discuss.elastic.co/u/radu_gheorghe)
#### Post date: [April 30, 2014, 10:27am UTC](https://discuss.elastic.co/t/read-write-consistency/17246/3 "2014-04-30T10:27:47Z")

</div>

Hi Mohit,

I'll answer inline.

On Mon, Apr 28, 2014 at 4:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:

> > Trying to understand the following scenarios of consistency in  
> > elasticsearch:
> > 
> > 1. sync replication - How does elasticsearch deals with consistency issue  
> > that may arise from 1 node momentarily going down and missing writes to it?

This depends on the write consistency setting. By default, the operation  
only succeeds if a quorum of replicas can index the document:

> **[Elastic — The Search AI Company](https://www.elastic.co)**
>
> Power insights and outcomes with The Elastic Search AI Platform. See into your data and find answers that matter with enterprise solutions designed to help you accelerate time to insight. Try Elastic ...

> When the node comes backup and the reads going to the non-primary shards
> 
> > could get inconsistent data?

No, when the node comes back up it will sync the stuff it missed with the  
other nodes.

> 1. async replication - What happens if replication is slow for some
> 
> > reason, could users see inconsistent data?

Yes, if you hit a shard that didn't get the latest operation, it could see  
an "old" version of the data. You can use "preference" to try and hit the  
primary shard all the time, but then your replicas will just be sitting  
there for redundancy:

> **[Elastic — The Search AI Company](https://www.elastic.co)**
>
> Power insights and outcomes with The Elastic Search AI Platform. See into your data and find answers that matter with enterprise solutions designed to help you accelerate time to insight. Try Elastic ...

> 1. sync/async replication - how does elasticsearch keep data in sync for
> 
> > those writes that never happened on the non-primary shard because of  
> > network/node failures?

It either uses the transaction log or it transfers the whole shard to that  
node.

## Best regards, Radu

Performance Monitoring \* Log Analytics \* Search Analytics  
Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)

--  
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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### Author: ![Mohit\_Anchlia](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@Mohit\_Anchlia](https://discuss.elastic.co/u/Mohit_Anchlia)
#### Post date: [May 1, 2014, 6:57pm UTC](https://discuss.elastic.co/t/read-write-consistency/17246/4 "2014-05-01T18:57:32Z")

</div>

What's not clear is how does elasticsearch identify what pieces of data is  
missing between the primary and the replica?

On Wed, Apr 30, 2014 at 3:27 AM, Radu Gheorghe  
[radu.gheorghe@sematext.com](mailto:radu.gheorghe@sematext.com)wrote:

> Hi Mohit,
> 
> I'll answer inline.
> 
> On Mon, Apr 28, 2014 at 4:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:
> 
> > > Trying to understand the following scenarios of consistency in  
> > > elasticsearch:
> > > 
> > > 1. sync replication - How does elasticsearch deals with consistency  
> > > issue that may arise from 1 node momentarily going down and missing writes  
> > > to it?
> 
> This depends on the write consistency setting. By default, the operation  
> only succeeds if a quorum of replicas can index the document:
> 
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-consistency)
> 
> > When the node comes backup and the reads going to the non-primary shards
> > 
> > > could get inconsistent data?
> 
> No, when the node comes back up it will sync the stuff it missed with the  
> other nodes.
> 
> > 1. async replication - What happens if replication is slow for some
> > 
> > > reason, could users see inconsistent data?
> 
> Yes, if you hit a shard that didn't get the latest operation, it could see  
> an "old" version of the data. You can use "preference" to try and hit the  
> primary shard all the time, but then your replicas will just be sitting  
> there for redundancy:
> 
> [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html)
> 
> > 1. sync/async replication - how does elasticsearch keep data in sync for
> > 
> > > those writes that never happened on the non-primary shard because of  
> > > network/node failures?
> 
> It either uses the transaction log or it transfers the whole shard to that  
> node.
> 
> ## Best regards, Radu
> 
> Performance Monitoring \* Log Analytics \* Search Analytics  
> Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)
> 
> --  
> 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> .  
> For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2\_UoJYobPqzxw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2_UoJYobPqzxw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### Author: ![radu\_gheorghe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe/32/556_2.png) [@radu\_gheorghe](https://discuss.elastic.co/u/radu_gheorghe)
#### Post date: [May 2, 2014, 6:57am UTC](https://discuss.elastic.co/t/read-write-consistency/17246/5 "2014-05-02T06:57:30Z")

</div>

Hi Mohit,

I think the transaction log takes care of that, because there's a copy on  
all instances of the same shard, and they need to be in sync.

Best regards,  
Radu

--  
Performance Monitoring \* Log Analytics \* Search Analytics  
Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)

On Thu, May 1, 2014 at 9:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:

> What's not clear is how does elasticsearch identify what pieces of data is  
> missing between the primary and the replica?
> 
> On Wed, Apr 30, 2014 at 3:27 AM, Radu Gheorghe \<[radu.gheorghe@sematext.com](mailto:radu.gheorghe@sematext.com)
> 
> > wrote:
> 
> > Hi Mohit,
> > 
> > I'll answer inline.
> > 
> > On Mon, Apr 28, 2014 at 4:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:
> > 
> > > > Trying to understand the following scenarios of consistency in  
> > > > elasticsearch:
> > > > 
> > > > 1. sync replication - How does elasticsearch deals with consistency  
> > > > issue that may arise from 1 node momentarily going down and missing writes  
> > > > to it?
> > 
> > This depends on the write consistency setting. By default, the operation  
> > only succeeds if a quorum of replicas can index the document:
> > 
> > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-consistency)
> > 
> > > When the node comes backup and the reads going to the non-primary
> > > 
> > > > shards could get inconsistent data?
> > 
> > No, when the node comes back up it will sync the stuff it missed with the  
> > other nodes.
> > 
> > > 1. async replication - What happens if replication is slow for some
> > > 
> > > > reason, could users see inconsistent data?
> > 
> > Yes, if you hit a shard that didn't get the latest operation, it could  
> > see an "old" version of the data. You can use "preference" to try and hit  
> > the primary shard all the time, but then your replicas will just be sitting  
> > there for redundancy:
> > 
> > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html)
> > 
> > > 1. sync/async replication - how does elasticsearch keep data in sync for
> > > 
> > > > those writes that never happened on the non-primary shard because of  
> > > > network/node failures?
> > 
> > It either uses the transaction log or it transfers the whole shard to  
> > that node.
> > 
> > ## Best regards, Radu
> > 
> > Performance Monitoring \* Log Analytics \* Search Analytics  
> > Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)
> > 
> > --  
> > 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> > .
> > 
> > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2\_UoJYobPqzxw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2_UoJYobPqzxw%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2\_UoJYobPqzxw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2_UoJYobPqzxw%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> .
> 
> For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### Author: ![Mohit\_Anchlia](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@Mohit\_Anchlia](https://discuss.elastic.co/u/Mohit_Anchlia)
#### Post date: [May 2, 2014, 4:33pm UTC](https://discuss.elastic.co/t/read-write-consistency/17246/6 "2014-05-02T16:33:04Z")

</div>

Is there a documentation on that? From what I've read it is local to the  
node.

On Thu, May 1, 2014 at 11:57 PM, Radu Gheorghe  
[radu.gheorghe@sematext.com](mailto:radu.gheorghe@sematext.com)wrote:

> Hi Mohit,
> 
> I think the transaction log takes care of that, because there's a copy on  
> all instances of the same shard, and they need to be in sync.
> 
> Best regards,  
> Radu
> 
> --  
> Performance Monitoring \* Log Analytics \* Search Analytics  
> Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)
> 
> On Thu, May 1, 2014 at 9:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:
> 
> > What's not clear is how does elasticsearch identify what pieces of data  
> > is missing between the primary and the replica?
> > 
> > On Wed, Apr 30, 2014 at 3:27 AM, Radu Gheorghe \<  
> > [radu.gheorghe@sematext.com](mailto:radu.gheorghe@sematext.com)\> wrote:
> > 
> > > Hi Mohit,
> > > 
> > > I'll answer inline.
> > > 
> > > On Mon, Apr 28, 2014 at 4:57 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com)wrote:
> > > 
> > > > > Trying to understand the following scenarios of consistency in  
> > > > > elasticsearch:
> > > > > 
> > > > > 1. sync replication - How does elasticsearch deals with consistency  
> > > > > issue that may arise from 1 node momentarily going down and missing writes  
> > > > > to it?
> > > 
> > > This depends on the write consistency setting. By default, the operation  
> > > only succeeds if a quorum of replicas can index the document:
> > > 
> > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-consistency)
> > > 
> > > > When the node comes backup and the reads going to the non-primary
> > > > 
> > > > > shards could get inconsistent data?
> > > 
> > > No, when the node comes back up it will sync the stuff it missed with  
> > > the other nodes.
> > > 
> > > > 1. async replication - What happens if replication is slow for some
> > > > 
> > > > > reason, could users see inconsistent data?
> > > 
> > > Yes, if you hit a shard that didn't get the latest operation, it could  
> > > see an "old" version of the data. You can use "preference" to try and hit  
> > > the primary shard all the time, but then your replicas will just be sitting  
> > > there for redundancy:
> > > 
> > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html)
> > > 
> > > > 1. sync/async replication - how does elasticsearch keep data in sync
> > > > 
> > > > > for those writes that never happened on the non-primary shard because of  
> > > > > network/node failures?
> > > 
> > > It either uses the transaction log or it transfers the whole shard to  
> > > that node.
> > > 
> > > ## Best regards, Radu
> > > 
> > > Performance Monitoring \* Log Analytics \* Search Analytics  
> > > Solr & Elasticsearch Support \* [http://sematext.com/](http://sematext.com/)
> > > 
> > > --  
> > > 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > > To view this discussion on the web visit  
> > > [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV\_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3aJ4qZt47uyjqs0gd6L1Fz0EhLrV_L7jzSFAYOEvz1Nw%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> > > .
> > > 
> > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2\_UoJYobPqzxw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2_UoJYobPqzxw%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2\_UoJYobPqzxw%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWpdBxiXZgDw5HXdeRPr5oJtnwHTwHNFr2_UoJYobPqzxw%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> > .
> > 
> > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com)[https://groups.google.com/d/msgid/elasticsearch/CAHXA0\_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAHXA0_3FAEvQGjMWDqSCT6biYJGiMNGSUDJ80QvT1cJXnqtNJg%40mail.gmail.com?utm_medium=email&utm_source=footer)  
> .
> 
> For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAOT3TWphfOYz%3DkFTH-NR6GeAna1oe3kq1je2Dz4iesePAS%3D%2BMA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAOT3TWphfOYz%3DkFTH-NR6GeAna1oe3kq1je2Dz4iesePAS%3D%2BMA%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

### 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, 1:32am UTC](https://discuss.elastic.co/t/read-write-consistency/17246/7 "2017-07-06T01:32:02Z")

</div>


