Cluster with 2 nodes changing shard type

Hi,
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.

I set 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.
for instance:

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: [1], total number of master-eligible nodes used for publishing in this round: [2])

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 :grinning:

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.

1 Like

Ok. Last thing: if I want to switch primary_shard[0] from node1 to node2 (and replica_shard[0] from node2 to 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.