How Raft consensus algorithm will make replication even better in MongoDB 3 2
summary
MongoDB 3.2 retrofits three Raft-inspired changes to make leader-based replication measurable and faster: it adds a raft election term (new T field plus recycled TS counter) so elections are distinct instead of waiting 30+ seconds, it collapses heartbeats into the replication stream so heartbeat via replication reduces false detects and scales with chained topologies, and it exposes a configurable election timeout with jitter to minimize ties — release candidate is available and these changes shorten failover and fix corner cases.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 0:30MongoDB replication
- 2:00Agenda
- 2:35Why do we need replication
- 4:00Performance
- 5:50Consensus
- 8:40What is consensus
- 9:15Leaderbased consensus
- 10:45MongoDB leaderbased consensus
- 13:25MongoDB splitbrain
- 18:55Why we did this
- 19:35Raft
- 28:00MongoDB Uplog
- 30:40Raft Election Term
- 32:50Raft Heartbeat
- 36:25Chained Replication
- 38:00Election Timeout
related talks
12mFault-Tolerant Replication with Pull-Based Consensus in MongoDB
47mDistributed Systems: When Democracy and Computer Science Come Together
41mThe Raft Consensus Algorithm
47mUnderstanding Raft Consensus
14mDistributed Consensus in 15 Minutes!
42mPractical Raft Consensus
51mDo Not Reimplement Distributed Consensus Algorithms
59mScaling Raft