Deconstructing Raft Consensus: Leader Leases, Pre-Vote, and Log Compaction

Executive Summary

In fault-tolerant distributed databases such as CockroachDB, TiKV, and etcd, the Raft consensus algorithm provides state machine replication across unreliable networks. This article breaks down production optimizations: implementing Pre-Vote to prevent partitioned nodes from destabilizing healthy clusters, utilizing leader leases to bypass round-trip disk writes on read operations, and log compaction protocols.

1. Consensus Guarantees & Safety Invariants

Raft guarantees safety through five foundational invariants: Election Safety, Leader Append-Only, Log Matching, Leader Completeness, and State Machine Safety. Unlike Paxos, Raft ensures that logs cannot contain uncommitted holes and that log entries flow strictly unidirectionally from Leader to Followers.

2. The Pre-Vote Protocol: Mitigating Disruptive Nodes

In standard Raft, if a node becomes partitioned from the cluster (e.g. disconnected from leader but able to increment its term counter), it will periodically time out, increment its term, and flood the network. When network connectivity restores, the higher term number forces the legitimate leader to immediately abdicate, triggering a disruptive re-election.

// Pre-Vote verification phase in Go
func (r *RaftNode) startPreVote() {
    r.state = StatePreCandidate
    votesGranted := 1 // self vote
    for _, peer := range r.peers {
        go func(p Peer) {
            req := PreVoteRequest{
                Term:         r.currentTerm + 1,
                CandidateID:  r.id,
                LastLogIndex: r.log.lastIndex(),
                LastLogTerm:  r.log.lastTerm(),
            }
            if resp := p.CallPreVote(req); resp.VoteGranted {
                r.mu.Lock()
                votesGranted++
                if votesGranted > len(r.peers)/2 && r.state == StatePreCandidate {
                    r.startRealElection() // Only increment term if quorum agrees!
                }
                r.mu.Unlock()
            }
        }(peer)
    }
}

3. Leader Leases for Zero-Overhead Linearizable Reads

Serving read queries directly from a leader without contacting followers risks returning stale data if the leader was partitioned without knowing it (split-brain). Raft solves this by default with a round-trip heartbeat verification (ReadIndex). However, by using bounded monotonic clock Leader Leases, a leader can serve reads locally with linearizable consistency as long as the lease window has not elapsed.

4. Log Compaction and Streaming Snapshots

Without truncation, the write-ahead log will eventually exhaust storage. Once log entries are applied to the state machine, they are condensed into a serialized point-in-time snapshot. Any laggy follower that falls behind beyond the retained log window is brought up to speed via chunked snapshot streaming over gRPC.

5. Frequently Asked Questions

Verified Sources & Documentation

• paper In Search of an Understandable Consensus Algorithm (Extended Version) — Diego Ongaro & John Ousterhout, Stanford University