Keep one agreed history when a leader fails

Replication can leave different machines with different amounts of history. When the leader fails, choosing any available machine is unsafe: it may lack an update already promised to a client.

Consensus is agreement on decisions despite some failures. For a database log, the repeated decisions form an ordered history. Raft is one protocol that combines log replication with leader election.

Begin with three voting servers

Use a fixed group A, B, and C. Participants obey the protocol, can crash and recover, and retain the protocol’s required durable state. Messages may be delayed or lost. A majority is two servers.

A is leader in term 4. A term is a numbered leadership period. A appends a new entry from its current term and durably replicates it to B. Under Raft’s rules, that majority replication allows A to commit the entry. Committing means it is part of the agreed history, not that every follower has already applied it.

Before A fails

A and B have entry X.
C has not received X.

The next election

Any two-server majority includes A or B.
Voting rules must protect the newer log.

Majorities intersect, but the participant in the intersection must follow rules that prevent an older history from winning.

If A crashes, B and C can still form a majority. Raft compares candidates’ log freshness when granting votes, using the last entry’s term and index. B will not vote for C’s older log in this example. B can become leader, preserve X, and bring C up to date.

Why counting replies is insufficient

The conclusion depends on the election rule, persistent votes, term handling, and restrictions on committing entries. In particular, Raft does not simply count replicas of an arbitrary old-term entry and declare it committed. Committing an entry from the current term establishes commitment of the preceding history through the protocol’s rules.

There are also read rules: an isolated former leader cannot assume it still has authority merely because it remembers being leader. Membership changes require their own protocol; replacing voters independently breaks the fixed-group reasoning.

A majority mechanism can preserve safety during a partition while preventing the minority from accepting new committed writes. Progress still depends on enough participants communicating and a leader remaining stable long enough.

Predict the partition

A is isolated from B and C. Can A commit a new entry using only its own durable copy in this three-voter group?

Count the available votes

No. One is not a majority of three. B and C may elect a leader and make progress under the protocol; A must not create a competing committed history. A client reaching only A may have to wait or receive an error.

Source: the Raft paper, especially leader election, log replication, and safety. This walkthrough explains one case; implementing Raft requires the complete protocol and failure tests, not just this example.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter