I think with current ES version you have 3 options. - Use the great snapshot and restore feature to snapshot from a DC and restore in the other one - Index in both DC (so two distinct clusters) from a client level - Use Tribe node feature to search or index on multiple clusters
Reference post https://groups.google.com/forum/#!searchin/elasticsearch/TribeNodes/elasticsearch/MG1RerVSWOk/qZFWvr0HPSwJ On Saturday, February 22, 2014 6:03:13 PM UTC-6, Michael Sick wrote: > > Hi Amit, > > Ivan is correct. You might also check out I believe that you're looking > for TribeNodes > http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/modules-tribe.html > and > see if it fits your needs for cross-dc replication. > > --Mike > > On Sat, Feb 22, 2014 at 1:32 PM, Amit Soni <[email protected]<javascript:> > > wrote: > >> Hello Michael - Understand that ES is not built to maintain consistent >> cluster state across data centers. what I am wondering is whether there is >> a way for ElasticSearch to continue to replicate data onto a different data >> center (with some delay of course) so that when the primary center fails, >> the fail over data center still has most of the data (may be except for the >> last few seconds/minutes/hours). >> >> Overall I am looking for a right way to implement cross data center >> deployment of elastic-search! >> >> -Amit. >> >> >> On Fri, Feb 21, 2014 at 9:37 AM, Michael Sick < >> [email protected] <javascript:>> wrote: >> >>> Dario, >>> >>> I believe that you're looking for TribeNodes >>> http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/modules-tribe.html >>> >>> ES is not built to consistently cluster across DC's / larger network >>> lags. >>> >>> On Fri, Feb 21, 2014 at 11:24 AM, Dario Rossi >>> <[email protected]<javascript:> >>> > wrote: >>> >>>> Hi, >>>> I've the following problem: our application publishes content to an >>>> Elasticsearch cluster. We use local data less node for querying >>>> elasticsearch then, so we don't use HTTP REST and the local nodes are the >>>> loadbalancer. Now they came with the requirement of having the cluster >>>> replicated to another data center too (and in the future maybe another >>>> too... ) for resilience. >>>> >>>> At the very beginning we thought of having one large cluster that goes >>>> across data centers (crazy). This solution has the following problems: >>>> >>>> - The cluster has the split-brain problem (!) >>>> - The client data less node will try to do requests across different >>>> data centers (is there a solution to this???). I can't find a way to avoid >>>> this. We don't want this to happen because of a) latency and b) >>>> firewalling >>>> issues. >>>> >>>> So we started to think that this solution is not really viable. So we >>>> thought of having one cluster per data center, which seems more sensible. >>>> But then here we have the problem that we must publish data to all >>>> clusters >>>> and, if one fails, we have no means of rolling back (unless we try to set >>>> up a complicated version based rollback system). I find this very >>>> complicated and hard to maintain, although can be somewhat doable. >>>> >>>> My biggest problem is that we have to keep the data centers in the same >>>> state at any time, so that if one goes down, we can readily switch to the >>>> other. >>>> >>>> Any ideas, or can you recommend some support to help use deal with this? >>>> >>>> -- >>>> 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 [email protected] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elasticsearch/5424a274-3f6b-4c12-9fe6-621e04f87a8d%40googlegroups.com >>>> . >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >>> 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 [email protected] <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elasticsearch/CAP8axnDW4GCDnnzwA%2BcyR%2BN4g-26VV4CZ-ZW6SDGgxFL75qy%2Bw%40mail.gmail.com >>> . >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elasticsearch/CAAOGaQKLUGepyKyR4oDNq1B7-uosp9SWCCeZmkRdQHsSJTSndA%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/9928e3f4-f7a4-43c5-8c4b-c42ece1d3234%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
