Over a million developers have joined DZone.

Overcoming Database Migration Fear

DZone's Guide to

Overcoming Database Migration Fear

Use the tools provided to you to try out flexible platforms that grow with your application. Check this out if you believe you are suffering from deebeephobia.

· Database Zone ·
Free Resource

Databases are better when they can run themselves. CockroachDB is a SQL database that automates scaling and recovery. Check it out here.

Image title

I used to be afraid of migrating databases as they’re typically at the heart and soul of an application. But as an application grows, it’s not uncommon for the database to outlive the original platform on which it was installed, making a migration absolutely necessary.

"And I came to realize it's that fear that's the worst of it. That's the real enemy." - Walter White

At a previous position I held, the "database problem" was one we dealt with constantly. We had an overwhelming sense of dread when we contemplated moving a database to another set of servers but none of us could really define the source of that fear. Perhaps it was just a general feeling that so much could go wrong in the process. To avoid migrations, we’d make weak attempts at caring for and feeding old servers — deleting old log files to free up disk space, throwing more CPU or RAM at the situation.

Rather than taking care of the problem for good, we allowed the problem to take over us. Overall, our operations team became less effective because we were spending more time on maintenance and putting out fires instead of building out new systems.

Defining Fear

Data loss or an outage in the process of a migration are big concerns. It's an uncommon fear but one I've actually created a scientific term for:

dee—bee—phobia; noun

  1. The intense fear that somehow migrating your database will be difficult

Ex: "The CTO has total deebeephobia over this entire migration to AWS!"

Major causes of deebeephobia:

  • Lack of knowledge.

    • Lack of information related to migration could create additional stress.

    • Not implementing best practices could put data at risk of security breaches.

  • Size of database; speed of network.

    • Database size could be large enough where it could take hours or days to copy over.

  • Speed of current system.

    • If the current hardware is not acceptable, would it be time to consider the cloud?

    • “Are the specs of the system I'm migrating to comparable to my existing system?”

  • The dynamic nature of database.

    • “Customers rarely stop; data needs to be read and written to my application regardless of the backend work I am doing.”

  • Potential outages.

    • Anything longer than a scheduled outages could harm the business.

      • Potential loss of users.

      • Potential loss of revenues.

This terrible affliction can be fought and overcome by even the least experienced systems operators by taking into account some careful steps. In this post, I'll go over how to plan for your database migration. We'll consider how to migrate a self-hosted MongoDB database into the cloud and cover some of the potential gotchas in the migration process. Let’s take the first steps to conquering our deebeephobia by planning for migrations properly.

Overcoming the Lack of Knowledge

Sometimes, the biggest barrier to upgrading a system is knowledge. If a database system was configured by a prior employee who did not fully document what they did, it can make for a difficult migration.

You may also want to spend some time performing an audit of the applications which are using the database being migrated.

Date Your Cloud Provider but Don't Marry Them

If you've already selected the MongoDB document model, you’ve selected the ability to remain dynamic with how you structure your data; I’d recommend a similar approach for choosing the public cloud in which your data layer will live. The ability to move quickly and select the right cloud platform for your app allows you to remain flexible. MongoDB Atlas provides you with a simple method to deploy, manage, and scale your database on all three of the major cloud providers: AWS, Microsoft Azure, and Google Compute Platform.

Without the overhead of lock-in to a particular cloud provider, you can ensure the best possible redundancy with data easily hosted in Google, AWS, or Azure. You can also leverage the service advantages of each cloud provider, based on your varying application needs.

MongoDB Atlas streamlines operating your data layer where ever you decide to host your data, giving you access to optimized instance types, network security, and data encryption, all of which can be easily configured with a click of your mouse.

Handling the Size of the Database and Speed of the Network

A migration can seem overwhelming if the size of your database is large. The size of your total data in use on disk and the speed of your network will ultimately determine how fast your database will migrate. If you're copying this data with rsync or a native utility, it may be wise for you to do some general testing of how long it takes for you to move a specific portion of your data.

One simple test (if using a UNIX-like system) is to create a dummy binary on your source and test how fast it imports to your target.

Create Binary:
bash-3.2$ dd if=/dev/zero of=1g.bin bs=1000000000 count=1
1+0 records in
1+0 records out
1000000000 bytes transferred in 1.603074 secs (623801585 bytes/sec)
bash-3.2$ du -sh 1g.bin
Test rsync speed
bash-3.2$ rsync -avz --progress./1g.bin ubuntu@
building file list...
1 file to consider
886308864 88% 147.05MB/s 0:00:00
1000000000 100% 143.51MB/s 0:00:06 (xfer#1, to-check=0/1)

My network moved this 1GB file pretty quickly — a good sign. This network speed is ideal for moving several hundreds of gigabytes to a few terabytes of data. Unfortunately, this ideal network situation is only part of the equation in a migration process; note that my database is not accepting new writes while being copied.

MongoDB Atlas's Live Migration service addresses this issue by allowing you to provide your source database's information and handling the data migration for you in the background. New writes to your source database will be replicated over to the target MongoDB Atlas database during the process. This ensures that your app can run uninterrupted during migration; simply modify the connection string to cut over your application to the new target database when it has caught up to the source.

Ensuring Performance

Regardless of where you’re migrating your database, it's important to ensure you're not migrating to a system that will degrade your application. Before migrating, be sure to check the CPU and memory of the infrastructure for your existing databases.

The db.runCommand() command returns a document that provides an overview of the database’s state.

db.runCommand( { serverStatus: 1 } )
"host" : "cluster0-shard-00-01-amprv.mongodb.net:27017",
"version" : "3.4.4",
"process" : "mongod",
"pid" : NumberLong(29050),
"uptime" : 1726776,
"uptimeMillis" : NumberLong(1726776634),
"uptimeEstimate" : NumberLong(1726776),
"localTime" : ISODate("2017-05-23T18:44:29.868Z"),
"asserts" : {
"regular" : 0,
"warning" : 0,
"msg" : 0,
"user" : 0,
"rollovers" : 0

CPU information can be obtained by executing cat (Linux) /proc/cpuinfo:

cat /proc/cpuinfo | grep 'model name' | uniq
model name: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
Memory information can be obtained by executing free (Linux):
free -m
total used free shared buff/cache available
Mem: 990 282 10 9 697 656
Swap: 1023 33 990

I have a small working set under 128MB and a system with a total of 1GB of RAM. If I were so inclined to migrate to a managed MongoDB service, the M10 instance size in MongoDB Atlas would be perfect. I can select my required disk size, which is 300GB, and enable SSD-based AES-256 encryption on the disk:

I am also one step closer to overcoming my deebeephobia by using MongoDB Atlas to handle most of the day-to-day administration work for me. Less work to do now and ess work to do in the future are both major advantages of migrating to Atlas.

Addressing the Need to Be Always on, Even During Migrations

Nothing can stop our app from running. Our customers will continue to access our app which means our database must always be able to accept new writes and updates. As we mentioned earlier, the MongoDB Atlas live migration service will permit you to run your app as usual during a migration by replicating all changes to your new database for you.

The oplog (operations log) is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. MongoDB applies database operations on the primary and then records those operations on the primary’s oplog. The secondary members then copy and apply these operations in an asynchronous process. All replica set members contain a copy of the oplog in the local.oplog.rs collection; this allows them to always catch up to the current state of the database.

MongoDB Atlas's live migration service will "tail" the oplog and apply all new changes until you're prepared to cut over. You can leave both the source and target databases online and have new updates applied to both. When you're ready to pause your app to new updates and cut over to the new database server in Atlas, your data will be up to date. There's no need for ad-hoc ingestion of missing documents or utilizing other methods to reconcile data; it's already been handled with Atlas live migration.

MongoDB Atlas live migration ensures that the train tracks for your data from your app to your database are always online.

Potential Outages

When MongoDB Atlas detects that the source and destination clusters are nearly in sync, it starts an extendable 72-hour timer to begin the cutover procedure. If the 72 hour period passes, Atlas stops synchronizing with the source cluster. You can extend the time remaining by 24 hours by clicking the “Extend time” hyperlink below the “<time> left to cut over” timer.

MongoDB Atlas significantly reduces the risk associated with migrating databases. There's no mistake on when you’re ready to cutover to the new database as you will be provided with a notice via email or within the browser when all the data is copied.

Don't be the danger to your application.

Migrations should not fill you with fear. And if that fear prevents you from performing a migration, you may have a bigger problem in the long run.

Take the time to do some investigation prior to moving to a new platform and you’ll be much more likely to achieve success.

Use the tools provided to you to try out flexible platforms that grow with your application. And if you believe you are suffering from deebeephobia, you may want to try out MongoDB Atlas as it significantly reduces the operational burden of migrating and running a database.

Databases should be easy to deploy, easy to use, and easy to scale. If you agree, you should check out CockroachDB, a scalable SQL database built for businesses of every size. Check it out here. 

database ,database migration ,data loss

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}