We recently helped a client migrate their MongoDB deployment from mLab to MongoDB Atlas and we figured what better opportunity for us to provide some insight to the cloud computing community than to share our experience and process.
mLab is a MongoDB as a service commonly used by many organization to manage their MongoDB clusters. This service was the go-to for Mongo-As-A-Service (MaaS for the purpose of this article), however more recently, mLab was acquired by MongoDB. We see it a a very strategic acquisition on the part of MongoDB because it allows them to transition users to their own MaaS, MongoDB Atlas.
MongoDB Atlas is a cloud platform that gives users direct access to their clusters running Mongo, and also gives them preference as to which cloud provider they'd like to run Mongo on. This gives an organization more direct DevOpsSec control over their deployments versus mLab which was strictly DB-as-a-service.
We gave MongoDB Atlas a test run before doing the full migration and we're more than impressed with the ease of use that comes with the platform, along with the granular control Atlas gives you over firewall rules, x509 certificate management, automated backups, and more.
If you're a DevOps professional that has managed your own MongoDB cluster, you'll immediately recognize Atlas's weight in gold as Atlas controls the sharding and maintenance of the cluster behind the scenes. They also handle automatic storage provisioning should your cluster exceed its storage requirements. This is a boon for DevOps professionals because it takes a lot of the grunt work out of having to re-provision your nodes to attach more storage.
Migrating from a self managed cluster or from mLab has a certain process associated with it that can summarized into the following stages:
Migration Planning: create a runbook of the steps you're going to use using the migration procedures provided by MongoDB. These may include planning for planned downtime, disabling new writes the old deployment, backing up your MongoDB data, etc.
Migration Process: actually doing the migration, provisioning your new Atlas cluster, using Mongodump, Import, or the automated replica-set control feature provided by Mongo.
Connectivity and Performance Testing: This includes checking connectivity, setting applicable fire wall rules, peering to your current cloud VPC, and other networking related work. From there you can do your benchmarking to test if your cluster is meeting your performance needs.
Switchover & De-comissioning: this inclues chancing your DB enivronment variable strings, updating your ORM packages in your actual code to use the new "mongo+srv://" URL structure, etc. From there, your source DB can be maintained for a few days while your new deployment is observed in production, before being safely decommissioned.
All in all, migrating any database in no small feat. MongoDB provides some great documentation as to the changes involved in their new drivers, however we certainly needed to update some of the NodeJS packages our client was using such as Mongoose to work with the new URL structure.
All in all, its good to have some experienced people on your team who have done large database migrations before with minimal downtime. If you'd like to talk to some experts who've done it with various databases, please feel free to call us for a chat and we'd be happy to help assess your needs, propose a runbook, and help get it done right with best-in-class cloud architecture.
Tags: mongodb, migration, mongodb atlas, database migration, database as a service, cloud architecture, kaizen technology