# Cluster to cluster replication **URL:** \ **Category:** Elasticsearch\ **Created:** [July 18, 2011, 3:09pm UTC](https://discuss.elastic.co/t/cluster-to-cluster-replication/4883 "2011-07-18T15:09:38Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Eran\_Kutner](https://avatars.discourse-cdn.com/v4/letter/e/e9c0ed/32.png) [@Eran\_Kutner](https://discuss.elastic.co/u/Eran_Kutner)\ **Post date:** [July 18, 2011, 3:09pm UTC](https://discuss.elastic.co/t/cluster-to-cluster-replication/4883/1 "2011-07-18T15:09:38Z")
Hi, I'm evaluating Elastic Search and so far I'm very impressed with it, however there are a few important features I think are missing. I will post about the other separately but one of the most important ones is cluster to cluster replication and it seems like it should not be difficult to achieve based on the current implementation. There are two motivations for replicating a whole cluster despite having shard replication already: 1. It allows geographic distribution of the content for performance and redundancy, where each location has its own cluster which is replicated to one or more other clusters. 2. It provides a hot recovery in case of a data corrupting bug in ES itself. The simplest implementation is a master/slave configuration where writes are only allowed to the master cluster and manual promotion is required in order to allow the slave to become a "master" and accept writes. This should be easily done if every node replicated its own writes, with their version numbers to the slave cluster/s. A more advanced configuration would allow active/active configuration where writes can go to both clusters but not on the same index. So basically, every index will have its own master cluster where writes are allowed and slaves where only reads are allowed. The most advanced configuration is full master/master configuration where writes are allowed to all the clusters and they can replicate data cyclically between themselves. This is obviously the ideal situation because it is a superset of the simpler scenarios described above. I'm not sure if this an be done as easily but I still think it's worth considering. It will require tagging the source cluster of each each update and propagating it as part of the replication so changes are not propagated back to their origin cluster. It will also require a method for resolving conflicts, while it is possible to use vector clocks and such, it is probably good enough to use simple timestamps to determine the most recent updates, especially since only full document updates are allowed. I'm wondering if this has been considered in the past, since I couldn't find anything about it in the mailing list? -eran ---
**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:** [July 18, 2011, 5:32pm UTC](https://discuss.elastic.co/t/cluster-to-cluster-replication/4883/2 "2011-07-18T17:32:53Z")
Heya, Yes, this certainly has been considered and discussed. Currently, you need to do it yourself on the client side, but, its certainly planned (though more down the road) to have cluster to cluster replication. -shay.banon On Mon, Jul 18, 2011 at 6:09 PM, Eran Kutner [eran@gigya.com](mailto:eran@gigya.com) wrote: > Hi, > I'm evaluating Elastic Search and so far I'm very impressed with it, > however there are a few important features I think are missing. I will > post about the other separately but one of the most important ones is > cluster to cluster replication and it seems like it should not be > difficult to achieve based on the current implementation. > There are two motivations for replicating a whole cluster despite > having shard replication already: > > 1. It allows geographic distribution of the content for performance > and redundancy, where each location has its own cluster which is > replicated to one or more other clusters. > 2. It provides a hot recovery in case of a data corrupting bug in ES > itself. > > The simplest implementation is a master/slave configuration where > writes are only allowed to the master cluster and manual promotion is > required in order to allow the slave to become a "master" and accept > writes. This should be easily done if every node replicated its own > writes, with their version numbers to the slave cluster/s. > > A more advanced configuration would allow active/active configuration > where writes can go to both clusters but not on the same index. So > basically, every index will have its own master cluster where writes > are allowed and slaves where only reads are allowed. > > The most advanced configuration is full master/master configuration > where writes are allowed to all the clusters and they can replicate > data cyclically between themselves. This is obviously the ideal > situation because it is a superset of the simpler scenarios described > above. I'm not sure if this an be done as easily but I still think > it's worth considering. It will require tagging the source cluster of > each each update and propagating it as part of the replication so > changes are not propagated back to their origin cluster. It will also > require a method for resolving conflicts, while it is possible to use > vector clocks and such, it is probably good enough to use simple > timestamps to determine the most recent updates, especially since only > full document updates are allowed. > > I'm wondering if this has been considered in the past, since I > couldn't find anything about it in the mailing list? > > -eran ---
**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, 4:00am UTC](https://discuss.elastic.co/t/cluster-to-cluster-replication/4883/3 "2017-07-06T04:00:16Z")