High availability multiple data center / crash recovery

Hi,

Does anyone figured out how to get a working Elasticsearch installation
with 2 data centers in 2 different zones ?

How do you get consistency ? Is it an active/active configuration ? How do
you manage network outages ?

I heard geoclustering is not a good idea. So if I have an active/passive
installation, how can I prevent data loss ? And replicate indexes ? (Both
with 0.90 and 1.X versions)

Thanks for ideas.

Cheers,
Yann

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/13f58770-061b-4f91-8af4-eafcfe68e080%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Yann,

we at AutoScout24 (http://www.autoscout24.de) have 3 independent clusters
in two data centers, fed with the same data and updated with around the
same frequency. The source of the data (an Oracle Database) resides in only
one of the data centers.
If you can afford this, you just don't have big network partitioning
problems. In case of one data center being isolated from the other, you
just have stale data in one data center, but no replication nor conflicts
nor data corruption issues.

We do not make clusters span over multiple locations and send traffic to
two of the three clusters, as one is just fed data and passively waiting
for traffic (hot standby). This later is reserved for catastrophic failures
in the main data center.
As we have independent indices which can handle the whole traffic, the data
originates from a database and building an index from scratch takes around
an hour, we do not back-up the index. We also automatically create a new
index with each new build and deployment process, all in a blue-green way
via Elasticsearch aliases.

I hope my description helps you decide on your architecture.

Florentin

Am Dienstag, 20. Mai 2014 17:57:49 UTC+2 schrieb Yann Barraud:

Hi,

Does anyone figured out how to get a working Elasticsearch installation
with 2 data centers in 2 different zones ?

How do you get consistency ? Is it an active/active configuration ? How do
you manage network outages ?

I heard geoclustering is not a good idea. So if I have an active/passive
installation, how can I prevent data loss ? And replicate indexes ? (Both
with 0.90 and 1.X versions)

Thanks for ideas.

Cheers,
Yann

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/04e8b1c6-b77e-481c-b46e-00220e748ff3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Florentin,

This is just great ! Thanks a lot. It looks like what I have in mid : 2
independent clusters, one on each site, fed with the same data (batchs or
live through virtual IP). Then, being active/active or active/passive is
just a matter of configuration.

Thanks again !

Cordialement,
Yann Barraud

2014-05-23 11:14 GMT+02:00 Florentin Zorca google@zorca.de:

Hi Yann,

we at AutoScout24 (http://www.autoscout24.de) have 3 independent clusters
in two data centers, fed with the same data and updated with around the
same frequency. The source of the data (an Oracle Database) resides in only
one of the data centers.
If you can afford this, you just don't have big network partitioning
problems. In case of one data center being isolated from the other, you
just have stale data in one data center, but no replication nor conflicts
nor data corruption issues.

We do not make clusters span over multiple locations and send traffic to
two of the three clusters, as one is just fed data and passively waiting
for traffic (hot standby). This later is reserved for catastrophic failures
in the main data center.
As we have independent indices which can handle the whole traffic, the
data originates from a database and building an index from scratch takes
around an hour, we do not back-up the index. We also automatically create a
new index with each new build and deployment process, all in a blue-green
way via Elasticsearch aliases.

I hope my description helps you decide on your architecture.

Florentin

Am Dienstag, 20. Mai 2014 17:57:49 UTC+2 schrieb Yann Barraud:

Hi,

Does anyone figured out how to get a working Elasticsearch installation
with 2 data centers in 2 different zones ?

How do you get consistency ? Is it an active/active configuration ? How
do you manage network outages ?

I heard geoclustering is not a good idea. So if I have an active/passive
installation, how can I prevent data loss ? And replicate indexes ? (Both
with 0.90 and 1.X versions)

Thanks for ideas.

Cheers,
Yann

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/LlZPkCpdy68/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/04e8b1c6-b77e-481c-b46e-00220e748ff3%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/04e8b1c6-b77e-481c-b46e-00220e748ff3%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CA%2BhvuXdP3Wwt-eByjoeP4m1jfE2pfRiDBOFwuA%3D_yW0wdeR1%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.