distributed-systemraftleader

When should a leader set voteFor to null while receiving a voteRequest with higher term in Raft?


Here is the Raft Paper: https://raft.github.io/raft.pdf

And I know every time responsing to or request for a RPC and accept a higher term, it will set its voteFor to null. in this link: In Raft distributed consensus, what do I set votedFor to? (is this rule right ?)

Assuming it's right, I wonder know, for a leader, when it receive a RequestVote from a candidate with higher term, should RequestVote be rejected to candidate because its voteFor is himself, or the voteFor has been set to null before this voting check ?

Here are some description mentioned in the paper.

RequestVote desription in Raft paper

And, what about it's wrong? In which case should a set a voteFor to null ?

By the way, are there any FAQs or worth reading of Raft should a read? Recommending them to me please!

PS: I' implementing Raft by C++ on Linux(Ubuntu22.04LTS).


Solution

  • Actually, I think I've found the answer here.

    For example, if you have already voted in the current term, and an incoming RequestVote RPC has a higher term that you, you should first step down and adopt their term (thereby resetting votedFor), and then handle the RPC, which will result in you granting the vote!

    Namely when receiving a voteReqest RPC with higher term, set voteFor to null and operate later log check, rather than just set voteFor to null and return false.

    Link: Raft Q&A