Moving MongoDB to the Cloud: Strategies and points to consider
summary
Describes two concrete migration paths: add a replica set member on cloud using rs.add and rs.stepDown for zero downtime with initial sync, or a physical backup/rsync approach that forces a cutover and risks catching up missed writes. Calls out measurable risks: increased write/read latency when using majority writeConcern, shards are hard to move, and security failures (default port, no auth) cause breaches. Recommends private networks, SSL, least-privilege users, monitor historical metrics, and avoid upgrading MongoDB or drivers during the move.
AI-written summary · about
chapters (6)
- 0:00Start
- 1:39MongoDB Hosting Options
- 5:27Strategy Planning
- 9:11Strategy #1 - Adding AWS MongoDB Server as a Replica Set Member - No Downtime Required
- 12:08Strategy #2 - Backup and Restore to AWS - Downtime is Required
- 14:15Latency
related talks
50mDeploying #MongoDB on public clouds: Architecture and options
40mData Migration Lessons from the Trenches
37mHow We Sharded and Migrated a 20 TB MongoDB Without Downtime
31mFrom Atlas to EKS How to Stay Sane and Save 45 During a Large‑Scale MongoDB Migration
32mA New Sharding Architecture for MongoDB
36mUnderstanding all the Options for Replica-sets and Replication Patterns
51m5 boring performance improvements in MongoDB 3.4 that matter
32mAutomating high availability MongoDB cluster deployment and management