Automating high availability MongoDB cluster deployment and management
summary
Flynn provisions and manages three-node replica set MongoDB clusters with an external state machine and service discovery, using discoverd with Raft to store cluster metadata and DNS leader records. Replication enforces a primary → sync → async chain, sets priorities/hidden flags so only the sync can be promoted, and expects clients to use majority read/write concerns. Known issues: MongoDB 3.2 can crash on rapid replica set config updates (workaround: sleep 5 seconds between changes). Data stored on ZFS, containers run via runc, CLI tunnels admin/backup commands.
AI-written summary · about
chapters (8)
- 0:00Flynn and database automation
- 4:20Why databases are hard
- 8:13MongoDB clusters for safety
- 14:40Live demo of MongoDB appliance
- 19:41Flynn architecture and scaling
- 23:37Use cases and production readiness
- 27:09Future plans for sharding
- 31:15Q&A
related talks
30mHow to Automate, Monitor and Manage your MongoDB Servers
44mHow Raft consensus algorithm will make replication even better in MongoDB 3 2
37mBuilding MongoDB Replica
44mHow Raft consensus algorithm will make replication even better in MongoDB 3 2
12mFault-Tolerant Replication with Pull-Based Consensus in MongoDB
35mBeyond Rapid Development - Jason Mimick
24mMoving MongoDB to the Cloud: Strategies and points to consider
54mBreakout Session