Raft Safety: Election Restriction and Leader Completeness

The guarantee that ties it together

Raft's key safety property is Leader Completeness: if an entry is committed in some term, it is present in the logs of all leaders of later terms. It follows from two rules you have already met. First, a committed entry sits on a majority. Second, the election restriction: a voter refuses any candidate whose log is less up-to-date than its own. A winning candidate needs votes from a majority, and that majority overlaps the majority holding the committed entry, so at least one voter has the entry. That voter would refuse a candidate missing it, so the winner must already have it. Combined with Log Matching and the current-term commit rule, this gives State Machine Safety: if a server has applied an entry at an index, no other server ever applies a different entry at that index. Notice the shape of the argument: it is the same quorum-intersection reasoning as Paxos, applied to elections.

Elections Raft must survive

Classic edge cases to rehearse: a leader that crashes after replicating an entry to a minority (the entry may be lost, which is fine because it was never committed); a leader that crashes after committing but before telling followers (the next leader still has it); and a partitioned old leader that keeps accepting writes it can never commit.

The class register

To become class representative, you need signatures from a majority of the class, and each student signs only for someone whose attendance register is at least as complete as their own. Any important entry already recorded by a majority therefore always ends up in the new representative's register.

Quick check: Which rule ensures a newly elected Raft leader already holds every committed entry?

• Followers forward their logs to the candidate before voting
• Leaders replay the whole log from a snapshot after election
• Voters reject candidates whose logs are less up-to-date than their own
• Only the server with the lowest ID may become leader