Can a leaving member become leader

[Fábio Botelho]

Hi all,

I'm confused with the Membership changes rules. 

It is clear from the thesis that a leaving member (which has appended a membership set that doesn't include him) needs to answer RPC's and vote for candidates, but it isn't clear (to me) if he can actually become leader.

Can anyone shed some light on the topic please?

Thanks in advance 

[Vilho Raatikka]

Hi Fabio, as I've understood, I'd say it is possible.

Based on the 'join consensus' mentioned in the short paper (Chapter 6.), when a member leaves, there is a period with both old, and new configurations. As it is said in the paper, 'any server from either configuration may serve as leader'.

It is the leader of the old configuration, which initiates, and runs the configuration change. The leader may itself be leaving, but if the leaving server is a follower, it may be elected as the new leader in the middle of the leaving process. If the old leader replicated the configuration change to the leaving node before losing leadership, the new leader eventually commits the change, the new configuration becomes the only existing one, and the leaving leader steps down.

Regards

Vilho Raatikka

[Fábio Botelho]

Thank you for your answer, but in my context, I'm only concerned about the single-server at a time membership change algorithm described in the thesis (my bad).

[Archie Cobbs]

FWIW, in my implementation that is not allowed: a node that is not part of its current configuration does not start elections and does not count its own vote.

I can't pinpoint exactly what the Raft paper says, but intuitively it wouldn't make sense. How can you participate in, and possibly win, an election, when you're not even a citizen?

Here's some relevant cut & paste from my own internal documentation...

Once a node is configured, a separate issue is whether the node is included in its own configuration, i.e., whether the node is a member of its cluster according to the current cluster configuration. A node that is not a member of its own cluster does not count its own vote to determine committed log entries (if a leader), and does not start elections (if a follower). However, it will accept and respond to incoming AppendRequests and RequestVotes.

In addition, leaders follow these rules with respect to configuration changes:

• If a leader is removed from a cluster, it remains the leader until the corresponding configuration change is committed (not counting its own vote), and then steps down (i.e., reverts to follower).
• If a follower is added to a cluster, the leader immediately starts sending that follower AppendRequests.
• If a follower is removed from a cluster, the leader continues to send that follower AppendRequests until the follower acknowledges receipt of the log entry containing the configuration change.
• Leaders defer configuration changes until they have committed at least one log entry in the current term (see this discussion).
• Configuration changes that remove the last node in a cluster are disallowed.
• Only one configuration change may take place at a time (i.e., be not yet committed).

-Archie

[Jesper Lindholm]

According to 4.1 in the thesis paper (towards the end):

 

“In Raft, it is the caller’s configuration that is used in reaching consensus, both for voting and for log replication: [..]

 

* A server also grants its vote to a candidate that is not part of the server’s latest configuration (if the candidate has a sufficiently up-to-date log and a current term). This vote may occasionally be needed to keep the cluster available. For example, consider adding a fourth server to a three-server cluster. If one server were to fail, the new server’s vote would be needed to form a majority and elect a leader.

 

Thus, servers process incoming RPC requests without consulting their current configurations.”

 

In other words, if a configuration with nodes A, B, D and E was appended to the log and the node C solicited a vote after this but before it has adopted the configuration, it could receive votes if the only thing that’s wrong is that doesn’t have the configuration yet. But the additional rules you lay out also make sense. Sounds to me like a case of picking your poison.

 

(Also, re-reading these sections, there seems to be some detail missing about what happens when a configuration change fails to go through and when it should be abandoned, although maybe since the configuration is a log entry, it is defined by log entry handling and left unsaid. It agrees with Archie’s point about there only being one configuration in-flight at a time: “Commitment of C-new allows three things to continue: [..] 3. Further configuration changes can be started. Before this point, overlapped configuration changes could degrade to unsafe situations like the one in Figure 4.2.”)

 

Regards,

/Jesper

--
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/6399b979-05ef-4d84-9a0f-828c8977b166n%40googlegroups.com.