Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

LeaseGuard: Raft Leases Done Right

A. Jesse Jiryu Davis, Murat Demirbas, Lingzhi Deng

TL;DR

LeaseGuard reframes leader leases for Raft by making the log itself the lease, leveraging Leader Completeness to ensure that a newly elected leader carries the previous lease. It introduces two optimizations—deferred commit writes and inherited lease reads—to maximize write and read availability during leader transitions, respectively, enabled by bounded-uncertainty clocks. The approach is formally specified in TLA+ and validated through Python simulation and a LogCabin implementation, showing dramatic reductions in local read latency (zero network round trips) and substantial write-throughput gains (roughly 10x) while improving availability during elections. Taken together, LeaseGuard offers a practical, high-availability solution for strongly consistent reads in Raft-based systems without altering the election protocol or adding extra messaging, with clear implications for cloud deployments relying on precise clocks.

Abstract

Raft is a leading consensus algorithm for replicating writes in distributed databases. However, distributed databases also require consistent reads. To guarantee read consistency, a Raft-based system must either accept the high communication overhead of a safety check for each read, or implement leader leases. Prior lease protocols are vaguely specified and hurt availability, so most Raft systems implement them incorrectly or not at all. We introduce LeaseGuard, a novel lease algorithm that relies on guarantees specific to Raft elections. LeaseGuard is simple, rigorously specified in TLA+, and includes two novel optimizations that maximize availability during leader failover. The first optimization restores write throughput quickly, and the second improves read availability. We evaluate LeaseGuard with a simulation in Python and an implementation in LogCabin, the C++ reference implementation of Raft. By replacing LogCabin's default consistency mechanism (quorum checks), LeaseGuard reduces the overhead of consistent reads from one to zero network roundtrips. It also improves write throughput from ~1000 to ~10,000 writes per second, by eliminating contention between writes and quorum reads. Whereas traditional leases ban all reads on a new leader while it waits for a lease, in our LeaseGuard test the new leader instantly allows 99% of reads to succeed.

LeaseGuard: Raft Leases Done Right

TL;DR

LeaseGuard reframes leader leases for Raft by making the log itself the lease, leveraging Leader Completeness to ensure that a newly elected leader carries the previous lease. It introduces two optimizations—deferred commit writes and inherited lease reads—to maximize write and read availability during leader transitions, respectively, enabled by bounded-uncertainty clocks. The approach is formally specified in TLA+ and validated through Python simulation and a LogCabin implementation, showing dramatic reductions in local read latency (zero network round trips) and substantial write-throughput gains (roughly 10x) while improving availability during elections. Taken together, LeaseGuard offers a practical, high-availability solution for strongly consistent reads in Raft-based systems without altering the election protocol or adding extra messaging, with clear implications for cloud deployments relying on precise clocks.

Abstract

Raft is a leading consensus algorithm for replicating writes in distributed databases. However, distributed databases also require consistent reads. To guarantee read consistency, a Raft-based system must either accept the high communication overhead of a safety check for each read, or implement leader leases. Prior lease protocols are vaguely specified and hurt availability, so most Raft systems implement them incorrectly or not at all. We introduce LeaseGuard, a novel lease algorithm that relies on guarantees specific to Raft elections. LeaseGuard is simple, rigorously specified in TLA+, and includes two novel optimizations that maximize availability during leader failover. The first optimization restores write throughput quickly, and the second improves read availability. We evaluate LeaseGuard with a simulation in Python and an implementation in LogCabin, the C++ reference implementation of Raft. By replacing LogCabin's default consistency mechanism (quorum checks), LeaseGuard reduces the overhead of consistent reads from one to zero network roundtrips. It also improves write throughput from ~1000 to ~10,000 writes per second, by eliminating contention between writes and quorum reads. Whereas traditional leases ban all reads on a new leader while it waits for a lease, in our LeaseGuard test the new leader instantly allows 99% of reads to succeed.

Paper Structure

This paper contains 35 sections, 2 theorems, 11 figures.

Table of Contents

  1. Introduction
  2. Background
  3. Raft
  4. Clocks with bounded uncertainty
  5. Adding leases to Raft
  6. Establishing a lease
  7. Deferred commit writes
  8. Inherited lease reads
  9. Correctness
  10. Raft guarantees
  11. Correctness with perfect clocks
  12. Correctness with clock uncertainty
  13. Correctness with reconfigurations
  14. Extensions and optimizations
  15. Automatic lease extension
  16. ...and 20 more sections

Key Result

Theorem 1

If a leader $L_1$ in term $t_1$ commits and applies write $w$, represented by log entry $e_1$ with index $i_1$, a later read $r$ must observe $w$'s effect.

Figures (11)

  • Figure 1: Raft replication. The leader advances its commitIndex when it learns that an entry is majority-replicated. Followers learn the new commitIndex from later AppendEntries messages.
  • Figure 2: LeaseGuard leader logic for a key-value store.
  • Figure 3: Logs of old leader $L_0$ and new leader $L_1$ just after $L_1$ was elected, before it commits any entry in its term.
  • Figure 4: Transitions in the read/write availability of leaders with LeaseGuard. While the new leader waits for a lease, it can serve some consistent reads and accept writes. Meanwhile the old leader serves reads.
  • Figure 5: Effect of lease duration on availability in LeaseGuard. Election timeout = $\Delta$ is usually optimal.
  • ...and 6 more figures

Theorems & Definitions (2)

  • Theorem 1: Read-Your-Writes
  • Theorem 2: Read At Highest commitIndex