currently I have a cluster with just 2 nodes. every index is divided just in 1 shard (indices are very very small) and 1 replica. I know that a cluster with 2 nodes has several limits but this is the state of art.
All the primaries shards are allocated on
node1, so if
node1 is restarted I cannot write into those indices.
is there a way to change this situation? I would like to avoid this interruption if node1 is restarted (manually by me or because there is a crash).
Personally I was thinking that if a replica shard lives alone in the cluster automatically will be elected as primary in that moment.
For a cluster to be highly available and accept writes with one node unavailable you need at least 3 master eligible nodes in the cluster.
So, with just two nodes I can have high availability for read operations but not for write? Is there a way to change the status of the replica shard if it remains alone?
If I rise the shard number from 1 to 2,is it possible that the write operation will choose the primary shard anyway?
Correct. Reads should still work.
I do not understand what you mean. Could you please explain?
You still need 3 nodes. With only 2 nodes no master can get elected with 1 node missing as a strict majority of nodes are needed (majority of 2 is 2). With 3 master eligible nodes the remaining 2 nodes can elect a master and writing can continue.
discovery.zen.minimum_master_nodes: 1 so I suppose that if one node goes down, automatically the other one will elect itself
master so in this way I was able also for write operations.
discovery.zen.ping.unicast.hosts: ["localhost", "node2"] discovery.zen.minimum_master_nodes: 1
I'm still using Elastic 5.6 but I have also another cluster on 6.8 with this configuration
If you do this then Elasticsearch logs the following warning:
[2019-09-20T07:40:41,956][WARN ][o.e.d.z.ElectMasterService] [node-1] value for setting "discovery.zen.minimum_master_nodes" is too low. This can result in data loss! Please set it to at least a quorum of master-eligible nodes (current value: , total number of master-eligible nodes used for publishing in this round: )
It's not kidding. This config will result in data loss.
The requirement for three master-eligible nodes isn't a restriction coming from Elasticsearch. It's not even theoretically possible to build a highly available distributed system using only two nodes.
hi @DavidTurner, that is the message
anyway, if I set that value and the
node1 is the only one available (
node2 is completely turned off) and my applications will try to contact the running one, I suppose that
node1 will be the master so will be available to write documents. isn't it?
Setting it that was means both nodes could form their own one node clusters when they are both up, which will guaranteed lead to data loss.
ok, but let me ask this: if the master
node1 goes down because I power it off and
node2 is elected master (because I set the
minimum_master:1), all the
node2's replica shards then will be considered as primary or not?
The behaviour is undefined if you have two master nodes and
discovery.zen.minimum_master_nodes: 1. Anything could happen.
If you have three master nodes and
discovery.zen.minimum_master_nodes: 2 then yes when you switch one node off any lost primaries will be replaced by promoting replicas on the other two nodes.
Ok. Last thing: if I want to switch primary_shard from
node2 (and replica_shard from
node1, is there a way to do that?
No, there's no way to do that. Primaries and replicas are pretty much equivalent, so there's normally no reason to care where the primary is currently located.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.