Leader election, leases and fencing tokens
Why a timeout cannot prove a leader is dead, how leases bound authority in time, and why only a fencing token checked by the resource stops a zombie leader.
30 min7 steps
By the end you can
- Explain split brain and why only intersecting quorums prevent two leaders in one term
- Size a lease's safety margin for clock drift and state what a lease assumes
- Explain how a paused or partitioned holder corrupts data, and how fencing tokens checked by the resource prevent it
Split brain: two leaders at once
Loading question…
Leases: authority with an expiry date
Grant
Authority for T seconds
Renew
Holder extends before expiry
Holder stops
Before expiry minus drift margin
Expiry
Grantor may now grant it elsewhere
Loading question…
The pause that breaks every lease
Loading question…
Fencing tokens: let the resource say no
Where fencing must live
Resource checks
- Compare-and-set
- Version check
- WHERE token <= ?
Client checks itself
- Protects nothing
- Pause hits after the check
No conditional write
- Idempotent operations
- STONITH: revoke credentials or power
Leases for reads, and what they assume
Heartbeat round (ReadIndex)
- Confirm with a majority
- One network round trip
Leader lease
- Followers hold off elections
- Local read, no round trip
- Needs bounded clock drift
Select minority partition in Script. The player shows stale-leader state, not leases.
Check your mastery, then fence a failover
Fencing off
split-brain write
Fencing on, same seed
no violation
Score 80% or more. In the sandbox, add a database with replicas and Automatic failover, Fence the old leader off. Kill the leader, let it recover, then switch fencing on and rerun.
Mastery check
5 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
Answer this step to continue.