clutsering- support for auto drop/bring members when unavailable/available again

[gooddaytocodeee]

in case there are 2 nodes:
1 leader, 1 follower

if their network connection is broken, both nodes become follower and keep trying to be a candidate, none of them can serve anymore

is it ok to just make them leader for a while until the connection is back?

[sakno]

Hi @gooddaytocodeee , no, it's not possible. Raft algorithm ensures linearizable reads and consistent writes. To do this, the write must be accepted by the majority of nodes. For instance, the cluster consisting of 3 nodes requires at least 2 nodes for the consensus. For 2 nodes the majority is 2 nodes. Without the consensus, the leader cannot perform replication of a single write. Optionally, you can set Partitioning configuration option to true to keep the leader as long as possible even if it doesn't see the majority (see docs for more info). However, it will be an ephemeral leader which cannot process any write request due to absence of the majority.

[gooddaytocodeee]

yes, thanks for your explan, but why a single leader can work properly(read&write without exception) with ColdStart=true, what't the majority then?

[sakno]

In case of coldStart=true, the node adds itself to the cluster membership automatically. The majority of the cluster consisting of 1 node is 1

[gooddaytocodeee]

Hi Sakno, since the majority can be 1, once the leader step down to follower due to heartbeat timeout, and failed to prevote to candidate for a specific times, other than keep failing, does it make sence to remove the disconnected members and serve as a single leader?

[sakno]

No, this is not intended behavior for a several reasons:

1. No way to distinguish temporary from permanent failures. What if the node is disconnected due to temp network failures (e.g. partitioning)?
2. The current implementation supports adding or removing one node at a time. Of course, you can add or remove as many nodes as you want during the lifetime of the cluster, but any uncommitted changes in the config must be related to a single node only. After the commit, you can apply necessary changes to another node.
3. Disconnected nodes may form the majority. For instance, you have 3 nodes, one of them is a leader. Imagine that two nodes are not available to the leader. But these 2 nodes still can communicate between each other, so they can form a new majority and elect a new leader.

[gooddaytocodeee]

OK, then I think the cluster really can not scale to 1 node only.