Adding a RAFT node to cluster with non-leader role

[AJ]

Hi, 

How can we add a node to a RAFT cluster with voting rights, but to never to become a leader. Having the node in the cluster with voting right means it will be able to participate in the election. 

Thanks in adv 

Anil. 

[Jinkun Geng]

This is an interesting question.

I feel it is related to the reconfiguration.

When this node is about to be added to the existing Raft cluster, it works as a client to submit one command, and wait for this command to be committed and executed.

This command will force the majority to agree that (1) this  client will join as a new replica (2) Never vote this new replica as leader

---

From: raft...@googlegroups.com <raft...@googlegroups.com> on behalf of AJ <anilj....@gmail.com>
Sent: Thursday, March 28, 2024 11:17 PM
To: raft-dev <raft...@googlegroups.com>
Subject: [raft-dev] Adding a RAFT node to cluster with non-leader role

 

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/37314808-b7a6-41e1-8e9d-e03d250961a2n%40googlegroups.com.

[Henrik Ingo]

Hi AJ

Mongodb does this, see https://www.mongodb.com/docs/manual/core/replica-set-elections/

(While MongoDB isn't Raft, thewait ections are.) 

Basically the node that first calls for an election usually becomes the leader, so lower priority nodes can just wait longer to let another node win.

Note however that you can't have a voting node "never" becoming a primary. You can only modify the likelihood, but every voting node must be ready to serve as primary if there's no better alternative.

Henrik 

[Henrik Ingo]

(2) is a problem. If you have members of a replica set that can't become leaders, they are essentially unavailable. The fact that you would allow them to influence elections makes it worse...

Imagine a 9 node cluster with nodes a b c d e can serve as leaders and f g h i can't. A network partition splits the cluster so that a-d are in a minority, so they can't choose a leader. e-i have majority and obviously e wins the elections. Later a-d reconnect to the cluster, but they're behind and need to do initial sync. Now e fails. The cluster is now unavailable even if only 1 node is down, 4 are recovering and 4 completely healthy.

To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/BYAPR02MB4613F203DD0CEBEE71F2AE0DD43A2%40BYAPR02MB4613.namprd02.prod.outlook.com.

[dr-dr xp]

If a voter that has the most recent logs, i.e., greatest `(last_term, last_log_index)`, and can not become a leader, then the cluster may be halt forever, because only the node with most latest log can become the leader.

I do not now the scenario you have but there is a solution to this issue:

Change **a voter never becoming leader** to **a voter that can elect and become the leader but can not propose new logs**.

Such a node becomes the leader and replicates old logs. Then some other node that can become leader and propose new logs will re-elect and become a new leader.

--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/37314808-b7a6-41e1-8e9d-e03d250961a2n%40googlegroups.com.

--

要了几天饱饭就不记得西北风啥味了