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
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
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 firstname.lastname@example.org.
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.