Summary
Leader election ensures only one node is authoritative at any time, preventing split-brain by using a consensus protocol that requires a quorum of nodes to agree before a leader is promoted: making it impossible for two nodes to simultaneously believe they are the leader.
Evidence
- ·Raft consensus requires a majority quorum for leader election: in a 3-node cluster, one partition side always loses
- ·ZooKeeper's leader election uses quorum writes: a node cannot become leader without acknowledgement from majority
- ·etcd (used by Kubernetes) uses Raft for leader election: a split partition with 2/5 nodes cannot elect a new leader
- ·PostgreSQL Patroni uses etcd/ZooKeeper for leader election to prevent two primaries simultaneously
- ·Kafka's controller leader election moved from ZooKeeper to KRaft (Kafka Raft) in Kafka 3.x
Operational Context
- ·Leader election timeout determines how long the system is unavailable during failover: trade-off between speed and correctness
- ·Leadership lease expiry must be shorter than the lease timeout: prevent a dead leader holding the lease indefinitely
- ·Monitor leader election events: frequent elections indicate network instability or undersized quorum
Tradeoffs
- ·Quorum-based election requires an odd number of nodes: a 2-node cluster cannot elect a leader after any partition
- ·Leader election adds a failover latency window (typically 5-30 seconds) during which the system is unavailable for writes
- ·The elected leader is a single point of throughput: all writes must go through the leader in a strong-consistency system
Evidence grounding
Grounded, 5 supporting itemsLeader election as a split-brain mitigation is foundational distributed systems knowledge, implemented in Raft, Paxos, ZooKeeper, and etcd. The consensus requirement is the formal proof of correctness against split-brain.