# 1 second index refresh and eventual consistency between nodes **URL:** \ **Category:** Elasticsearch\ **Created:** [August 24, 2011, 5:08pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242 "2011-08-24T17:08:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Spring\_Ninja](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spring_ninja/32/2719_2.png) [@Spring\_Ninja](https://discuss.elastic.co/u/Spring_Ninja)\ **Post date:** [August 24, 2011, 5:08pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/1 "2011-08-24T17:08:42Z")
Hi there, Could someone clarify the index refresh behavior. I understand and see in my app and tests that the writes are made visible to my (currently) single node app at 1 second intervals. My app will be a multi-node cluster with each app node also acting as an embedded ES. Question is: Will an update to master node A be made available to the replicas within that 1 second refresh period, or is this only true for the local node? We have [https://github.com/elasticsearch/elasticsearch/issues/1063](https://github.com/elasticsearch/elasticsearch/issues/1063) where there is talk of having blocking calls where a write will only come back when it is visible everywhere. Is that possible or will that only be possible in a single node architecture? Thanks, Rémy ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 24, 2011, 5:29pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/2 "2011-08-24T17:29:40Z")
When a document is indexed, it goes through the primary shard, and replicated to the replica shards. The master node plays no part here. Each shard (primary and replica) have a refresh interval, once a refresh is executed, then the operations done against it from the last refresh are visible for _search_. Note, get has "realtime" visibility. More answers below: On Wed, Aug 24, 2011 at 8:08 PM, Spring Ninja [remy.gendron@ingeno.ca](mailto:remy.gendron@ingeno.ca)wrote: > Hi there, > > Could someone clarify the index refresh behavior. I understand and see > in my app and tests that the writes are made visible to my (currently) > single node app at 1 second intervals. > > My app will be a multi-node cluster with each app node also acting as > an embedded ES. > > Question is: Will an update to master node A be made available to the > replicas within that 1 second refresh period, or is this only true for > the local node? No, indexing data means they get indexing in the relevant nodes / shards. Refresh interval is a agnostic to that. > We have ["block until refresh" indexing option · Issue #1063 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/1063) > where there is talk of having blocking calls where a write will only > come back when it is visible everywhere. Is that possible or will that > only be possible in a single node architecture? If its implemented, we should be able to implement it for a multi node case as well. > Thanks, > > Rémy ---
**Author:** ![Spring\_Ninja](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spring_ninja/32/2719_2.png) [@Spring\_Ninja](https://discuss.elastic.co/u/Spring_Ninja)\ **Post date:** [August 24, 2011, 9:15pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/3 "2011-08-24T21:15:56Z")
That would be really awesome and would simplify a lot of use cases. Such as updating an edit screen and being able to navigate and immediately update the associated list screen and see the results of the update consistently. An indexAndBlockUntilReplicatedAndVisible flag in the request would be great. On Aug 24, 1:29 pm, Shay Banon [kim...@gmail.com](mailto:kim...@gmail.com) wrote: > When a document is indexed, it goes through the primary shard, and > replicated to the replica shards. The master node plays no part here. > > Each shard (primary and replica) have a refresh interval, once a refresh is > executed, then the operations done against it from the last refresh are > visible for _search_. Note, get has "realtime" visibility. > > More answers below: > > On Wed, Aug 24, 2011 at 8:08 PM, Spring Ninja [remy.gend...@ingeno.ca](mailto:remy.gend...@ingeno.ca)wrote: > > > Hi there, > > > Could someone clarify the index refresh behavior. I understand and see > > in my app and tests that the writes are made visible to my (currently) > > single node app at 1 second intervals. > > > My app will be a multi-node cluster with each app node also acting as > > an embedded ES. > > > Question is: Will an update to master node A be made available to the > > replicas within that 1 second refresh period, or is this only true for > > the local node? > > No, indexing data means they get indexing in the relevant nodes / shards. > Refresh interval is a agnostic to that. > > > We havehttps://github.com/elasticsearch/elasticsearch/issues/1063 > > where there is talk of having blocking calls where a write will only > > come back when it is visible everywhere. Is that possible or will that > > only be possible in a single node architecture? > > If its implemented, we should be able to implement it for a multi node case > as well. > > > Thanks, > > > Rémy ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 25, 2011, 1:37pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/4 "2011-08-25T13:37:23Z")
Just curious how this differs from passing refresh=true in the index request? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 25, 2011, 2:23pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/5 "2011-08-25T14:23:14Z")
It will not force a refresh on each request, instead, it will block the response from returning until a refresh happened (the periodic one). On Thu, Aug 25, 2011 at 4:37 PM, James Cook [jcook@tracermedia.com](mailto:jcook@tracermedia.com) wrote: > Just curious how this differs from passing refresh=true in the index > request? ---
**Author:** ![James\_Cook](https://avatars.discourse-cdn.com/v4/letter/j/898d66/32.png) [@James\_Cook](https://discuss.elastic.co/u/James_Cook)\ **Post date:** [August 25, 2011, 6:09pm UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/6 "2011-08-25T18:09:00Z")
I see. So the end result is the same, but forcing the refresh is disruptive to performance. We could definitely benefit from this functionality also. We use refresh now, but our writes are minimal (at the moment) so we don't notice much impact. ---
**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, 3:56am UTC](https://discuss.elastic.co/t/1-second-index-refresh-and-eventual-consistency-between-nodes/5242/7 "2017-07-06T03:56:00Z")