# ES default - async or sync **URL:** \ **Category:** Elasticsearch\ **Created:** [September 7, 2014, 1:38am UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654 "2014-09-07T01:38:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![daa\_qqu](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@daa\_qqu](https://discuss.elastic.co/u/daa_qqu)\ **Post date:** [September 7, 2014, 1:38am UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654/1 "2014-09-07T01:38:12Z")
What is the default replication policy in Elasticsearch? Does it push changes to replicas asynchronously or synchronously? Or does it use different mode with different operations. asynchronous replication [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index\_.html#index-replication](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-replication) By default, the index operation only returns after all shards within the replication group have indexed the document (sync replication). optimistic concurrency control [http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control) Elasticsearch is distributed. When documents are created, updated or deleted, the new version of the document has to be replicated to other nodes in the cluster. Elasticsearch is also asynchronous and concurrent This book Ealsticsearch Definitive Guide, states under 'Creating, indexing and deleting' that "...default value for replication is synchronous". When discussing 'update' API it is stated that "...these changes are forwarded to the replica shards asynchronously...." > replication \*\*\* The default value for replication is sync. This causes the primary shard to wait for successful responses from the replica shards before returning. > Document based replication When a primary shard forwards changes to its replica shards, it doesn’t forward the update request. Instead it forwards the new version of the full document. \*\*\*Remember that these changes are forwarded to the replica shards asynchronously and there is no guarantee that they will arrive in the same order that they were sent. -- 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/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [September 7, 2014, 8:31am UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654/2 "2014-09-07T08:31:17Z")
Hiya OK I see where the confusion is coming in. I used the word asynchronously in slightly different contexts there. I will try to reword in the Definitive Guide. Replication is sync by default, in other words: the primary waits for indexing to happen on the replica before it returns to the user. That said, lots of these processes happen at the same time, so sending the document to the replica is asynchronous. It doesn't send a change then wait for the response before sending the next one. This all happens in parallel. Does that make it clearer? On 7 September 2014 03:38, daa qqu [daaqqu@gmail.com](mailto:daaqqu@gmail.com) wrote: > What is the default replication policy in Elasticsearch? Does it push > changes to replicas asynchronously or synchronously? Or does it use > different mode with different operations. > asynchronous replication > [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index\_.html#index-replication](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-replication) > > By default, the index operation only returns after all shards within the > replication group have indexed the document (sync replication). > optimistic concurrency control > [http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control) > Elasticsearch is distributed. When documents are created, updated or > deleted, the new version of the document has to be replicated to other > nodes in the cluster. Elasticsearch is also asynchronous and concurrent > > This book Ealsticsearch Definitive Guide, states under 'Creating, indexing > and deleting' that "...default value for replication is synchronous". When > discussing 'update' API it is stated that "...these changes are forwarded > to the replica shards asynchronously...." > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/15\_Create\_index\_delete.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/15_Create_index_delete.asciidoc) > replication > > \*\*\* The default value for replication is sync. This causes the primary > shard to wait for successful responses from the replica shards before > returning. > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/25\_Partial\_updates.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/25_Partial_updates.asciidoc) > > Document based replication > > When a primary shard forwards changes to its replica shards, it doesn’t > forward the update request. Instead it forwards the new version of the full > document. \*\*\*Remember that these changes are forwarded to the replica > shards asynchronously and there is no guarantee that they will arrive in > the same order that they were sent. > > -- > 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/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%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/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![daa\_qqu](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@daa\_qqu](https://discuss.elastic.co/u/daa_qqu)\ **Post date:** [September 8, 2014, 2:05am UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654/3 "2014-09-08T02:05:28Z")
Wow! Straight from the author. Thank you Clinton!! Makes sense now. On Sun, Sep 7, 2014 at 1:31 AM, Clinton Gormley [clint@traveljury.com](mailto:clint@traveljury.com) wrote: > Hiya > > OK I see where the confusion is coming in. I used the word asynchronously > in slightly different contexts there. I will try to reword in the > Definitive Guide. > > Replication is sync by default, in other words: the primary waits for > indexing to happen on the replica before it returns to the user. That > said, lots of these processes happen at the same time, so sending the > document to the replica is asynchronous. It doesn't send a change then > wait for the response before sending the next one. This all happens in > parallel. > > Does that make it clearer? > > On 7 September 2014 03:38, daa qqu [daaqqu@gmail.com](mailto:daaqqu@gmail.com) wrote: > > > What is the default replication policy in Elasticsearch? Does it push > > changes to replicas asynchronously or synchronously? Or does it use > > different mode with different operations. > > asynchronous replication > > [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index\_.html#index-replication](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-replication) > > > > By default, the index operation only returns after all shards within the > > replication group have indexed the document (sync replication). > > optimistic concurrency control > > [http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control) > > Elasticsearch is distributed. When documents are created, updated or > > deleted, the new version of the document has to be replicated to other > > nodes in the cluster. Elasticsearch is also asynchronous and concurrent > > > > This book Ealsticsearch Definitive Guide, states under 'Creating, > > indexing and deleting' that "...default value for replication is > > synchronous". When discussing 'update' API it is stated that "...these > > changes are forwarded to the replica shards asynchronously...." > > > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/15\_Create\_index\_delete.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/15_Create_index_delete.asciidoc) > > replication > > > > \*\*\* The default value for replication is sync. This causes the primary > > shard to wait for successful responses from the replica shards before > > returning. > > > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/25\_Partial\_updates.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/25_Partial_updates.asciidoc) > > > > Document based replication > > > > When a primary shard forwards changes to its replica shards, it doesn’t > > forward the update request. Instead it forwards the new version of the full > > document. \*\*\*Remember that these changes are forwarded to the replica > > shards asynchronously and there is no guarantee that they will arrive in > > the same order that they were sent. > > > > -- > > 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/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%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/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAPt3XKQVHAYL9aarQK%2Bf5cZHu3c7LFJ5qEGX%3DrDjShPU%2B3fSvA%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/CAO4Z2jAYNJuLTmSoTPt%2BG%2BUg2BPnQnBa7w2BvKDgHx\_R03aGGQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jAYNJuLTmSoTPt%2BG%2BUg2BPnQnBa7w2BvKDgHx_R03aGGQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![ElasticSearch\_Users\_](https://avatars.discourse-cdn.com/v4/letter/e/b4bc9f/32.png) [@ElasticSearch\_Users\_](https://discuss.elastic.co/u/ElasticSearch_Users_)\ **Post date:** [February 2, 2015, 2:26pm UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654/4 "2015-02-02T14:26:56Z")
Hi Clinton, Is using async NOT recommonded? The Definitive Guild says, "This option is mentioned specifically to _advise against using it_. The default sync replication allows Elasticsearch to exert back pressure on whatever system is feeding it with data. With async replication, it is possible to _overload Elasticsearch_ by sending too many requests without waiting for their completion." Also, if the indexes has _not_ being updated in the replica, could the query only be sent to the replica and elasticsearch return not found? On Sunday, 7 September 2014 04:31:30 UTC-4, Clinton Gormley wrote: > Hiya > > OK I see where the confusion is coming in. I used the word asynchronously > in slightly different contexts there. I will try to reword in the > Definitive Guide. > > Replication is sync by default, in other words: the primary waits for > indexing to happen on the replica before it returns to the user. That > said, lots of these processes happen at the same time, so sending the > document to the replica is asynchronous. It doesn't send a change then > wait for the response before sending the next one. This all happens in > parallel. > > Does that make it clearer? > > On 7 September 2014 03:38, daa qqu \<[daa...@gmail.com](mailto:daa...@gmail.com) \\> wrote: > > > What is the default replication policy in Elasticsearch? Does it push > > changes to replicas asynchronously or synchronously? Or does it use > > different mode with different operations. > > asynchronous replication > > [http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index\_.html#index-replication](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html#index-replication) > > > > By default, the index operation only returns after all shards within the > > replication group have indexed the document (sync replication). > > optimistic concurrency control > > [http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/optimistic-concurrency-control.html#optimistic-concurrency-control) > > Elasticsearch is distributed. When documents are created, updated or > > deleted, the new version of the document has to be replicated to other > > nodes in the cluster. Elasticsearch is also asynchronous and concurrent > > > > This book Ealsticsearch Definitive Guide, states under 'Creating, > > indexing and deleting' that "...default value for replication is > > synchronous". When discussing 'update' API it is stated that "...these > > changes are forwarded to the replica shards asynchronously...." > > > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/15\_Create\_index\_delete.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/15_Create_index_delete.asciidoc) > > replication > > > > \*\*\* The default value for replication is sync. This causes the primary > > shard to wait for successful responses from the replica shards before > > returning. > > > > [https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040\_Distributed\_CRUD/25\_Partial\_updates.asciidoc](https://github.com/elasticsearch/elasticsearch-definitive-guide/blob/master/040_Distributed_CRUD/25_Partial_updates.asciidoc) > > > > Document based replication > > > > When a primary shard forwards changes to its replica shards, it doesn’t > > forward the update request. Instead it forwards the new version of the full > > document. \*\*\*Remember that these changes are forwarded to the replica > > shards asynchronously and there is no guarantee that they will arrive in > > the same order that they were sent. > > > > -- > > 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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com) > > [https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAO4Z2jCOfD8Mp8YL9WbPmf9aODX4D6fORZ-pSjhxFx1qweQsXA%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/890150aa-3ccd-48f1-8cc0-8115f756fcb6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/890150aa-3ccd-48f1-8cc0-8115f756fcb6%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**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, 12:35am UTC](https://discuss.elastic.co/t/es-default-async-or-sync/19654/5 "2017-07-06T00:35:21Z")