Solving Raft's practical problems in Tarantool. What, how and why
summary
Tarantool adds Raft but changes three practical pieces: nodes voluntarily resign when quorum of live connections is lost so an isolated old leader stops blocking writes; a pre-vote-like probe that piggybacks “do you see the leader?” prevents elections during partial network splits without changing the wire protocol much; election rounds abort early via vote-count gossip to avoid waiting full 5s timeouts; and operational fixes include fencing by halving leader timeout, manual quorum lowering, and split‑brain detection via multiplexed mode records.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:09What is Raft and its guarantees
- 8:11Raft implementation expectations vs reality
- 13:54Raft in Tarantool specifics
- 17:05Disconnection loss problem and pre-vote solution
- 23:44Optimal pre-vote solution
- 28:59Leader change speedup via vote counting
- 31:09Multiple leaders problem and fencing
- 40:52Fencing mechanism and tuning
- 49:09Manual leader control and quorum reduction
- 55:33Summary and results
- 56:59Q&A
related talks
42mPractical Raft Consensus
41mThe Raft Consensus Algorithm
47mDistributed Systems: When Democracy and Computer Science Come Together
21mUsing Raft in Rust
47mUnderstanding Raft Consensus
55mImplementing Raft in RabbitMQ
44mImproving Raft Survivability in Real-World Conditions
01h 32mHow to Reach Consensus with Paper, Pencil and the Raft Algorithm