In non "big data" scenarios, having two servers for a database is simply
done to achieve high availability. Most databases use a master client
scenario, but Elasticsearch does not support such a setup. It really should
because not everyone has tons of data.
Ivan, not affiliated with the OP
On May
Looks like the only way around this would be to add more nodes and set
minimum masters to ensure a majority quorum.
Thanks.
Gourav
On Monday, 4 May 2015 12:02:27 UTC+5:30, Jason Wee wrote:
>
> why must you have only two nodes, would it be possible to add one more
> nodes so split brain will
why must you have only two nodes, would it be possible to add one more
nodes so split brain will not become an issue?
jason
On Mon, May 4, 2015 at 2:20 PM, Mark Walkom wrote:
> Your nodes aren't in different DCs are they? If so this is why we don't
> support such setups, because ES is latency s
Your nodes aren't in different DCs are they? If so this is why we don't
support such setups, because ES is latency sensitive and these sorts of
things can happen very easily when your network is unreliable.
They don't try to ping other nodes because you only have two, and if they
lose contact with
1) After network goes down, they loose communication with each other. After
that, they are becoming split.
2) They both think they are masters. Even if they think they are masters,
shouldn't the ping happen to see if there are other nodes in the cluster ?
3) Number of replicas is set to 1. If ES
1. Why are they becoming split anyway? GC, other load, network?
2. Not if they both think they are masters.
3. Are you running replicas? If so ES doesn't really differentiate
between the two.
On 4 May 2015 at 15:03, Gourav H Dhelaria wrote:
> Version: 1.4.
> Say there are 2 nodes X
