Scaling Raft
summary
ScyllaDB adds Raft (since 5.0) to manage topology, schema and eventually data, running thousands of Raft groups per node (hundreds of thousands of partitions across large clusters). Key engineering moves: replace per-group heartbeats with shared failure detection, make the randomized election wait grow with cluster size (scale election timeout), and add entry forwarding and inverse pings so followers need not ping leaders constantly. Raft extensions include joint consensus, pre-voting and non‑voting support; simulations and nemesis tests show the approach holds up while work continues on multi‑Raft data replication.
AI-written summary · about
chapters (7)
- 0:00Start
- 14:45ow Raft Achieves Consistency
- 18:15etecting a leader failure
- 20:39aft Leadership Changes
- 27:21olution: shared failure detector
- 31:30aft Configuration Changes
- 39:31ticky leadership rule removed
related talks
47mDistributed Systems: When Democracy and Computer Science Come Together
30mOvercoming Distributed Databases Scaling Challenges with Tablets
41mThe Raft Consensus Algorithm
47mUnderstanding Raft Consensus
44mHow Raft consensus algorithm will make replication even better in MongoDB 3 2
55mImplementing Raft in RabbitMQ
44mHow Raft consensus algorithm will make replication even better in MongoDB 3 2
43mRa: a Raft implementation