You can try winding out the timeouts, see http://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html#fault-detection
On 31 March 2015 at 16:57, Neil Andrassy <neil.andra...@thefilter.com> wrote: > It's probably something like that, but it only seems to be a problem with > the more up to date version of ES. I'm keen to work out if there's a > configuration option I can tweak in 1.4.4 to make ES more robust in this > scenario or whether there's an issue around recovering dropped TCP > connections between nodes in more recent versions. > > On Tuesday, 31 March 2015 03:33:18 UTC+1, Mark Walkom wrote: >> >> It's not the VPN reconnecting is it? >> >> On 31 March 2015 at 01:32, Neil Andrassy <neil.a...@thefilter.com> wrote: >> >>> Hi, >>> >>> I have two independent clusters running across more or less the same >>> machines. They're split across a pretty high bandwidth and relatively low >>> latency VPN link. One cluster is running v1.0.1 and seems to stay up all >>> the time. The other cluster is currently running 1.4.4 (and was running >>> 1.4.2 before that) and seems to disconnect like clockwork every two hours. >>> The disconnect of the nodes on one side of the link is brief, they rejoin >>> and the recovery proceeds as normal. Any ideas what might cause this? Could >>> it be data related? The newer cluster has more indexes & shards than the >>> old, but the co-ordinators (3 of / min master count 2) don't seem >>> particularly stressed. Any thoughts on what, specifically to look for or >>> whether any particular setting or code change might make the cluster more >>> susceptible to disconnect when there's a minor / brief network connectivity >>> blip? >>> >>> (and yes, I know multi-site isn't a recommended configuration - there >>> are other challenges for us with the tribe node approach too, though :( ) >>> >>> Thanks in advance for any ideas or insight. >>> >>> N >>> >>> -- >>> 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. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/elasticsearch/b00b8bda-9238-47e8-b0f2-3d4d6751b3c2% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/elasticsearch/b00b8bda-9238-47e8-b0f2-3d4d6751b3c2%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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/793f13a8-9ca8-4d86-b194-47b4e9cd5125%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/793f13a8-9ca8-4d86-b194-47b4e9cd5125%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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEYi1X_fbZXbP_iY4ZpJODXPmumh15CntRT6S4HaJdrvqv593A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
