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:
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.”)
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.