How to Evaluate MongoDB 3.4 Using Your Existing Deployment in MongoDB Atlas

December 4, 2016

MongoDB 3.4 was just released with support for graph processing, multi-language collations, read-only views, faceted navigation, powerful new aggregation operators, numerous performance improvements, and more. MongoDB 3.4 is available in the MongoDB Atlas database service today, so you can quickly and easily deploy new clusters and try it out. But what’s the best way to evaluate MongoDB 3.4 against an existing production workload you have running in MongoDB Atlas? As with any software upgrade, you should first test your application.

MongoDB Atlas automates spinning up new production-ready MongoDB clusters, manages backups and restores, and automates on-demand upgrades of MongoDB from 3.2 to 3.4 at any time. By combining these capabilities, you can very easily:

  1. Spin up a test environment from a backup
  2. Upgrade the test environment from MongoDB 3.2 to MongoDB 3.4
  3. Confirm that your testing and performance suite pass on MongoDB 3.4

Specifically, in this tutorial we’re going to:

  1. Start with a production MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 with the Atlas backup service enabled.
  2. Spin up a new MongoDB Atlas test cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with sufficient storage to restore the production cluster’s backup.
  3. Restore the most recent backup snapshot from the production cluster into the test cluster.
  4. Upgrade the test cluster from MongoDB 3.2 to MongoDB 3.4
  5. Execute our test suite against the MongoDB 3.4 test cluster.
  6. If all goes well, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster. This upgrade will be made in-place, and will be completed without application downtime.

1. Start with a MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 and with the Atlas backup service enabled.

For purposes of this tutorial, we have pre-loaded this cluster and have it under active load.

MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 and with the Atlas backup service enabled

2. Create a new MongoDB Atlas cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with enough storage to restore the production cluster’s backup.

We’ll follow the “Add new cluster” flow and deploy an M20 instance with 40GB of storage, just like our production cluster in this example. Note that for your live production deployments, we do recommend that you run on a MongoDB Atlas M30 or higher.

Create a new MongoDB 3.4 Atlas Cluster

After the cluster deploys, we’ll see the following:

MongoDB Atlas cluster after deployment

3. Restore the most recent backup snapshot from the production cluster into the test upgrade cluster.

We’ll navigate into the “Backup” tab and find the backup for our production cluster.

Backup for production cluster

Click into the Options menu (“...”) and select “Restore”.

Choose the most recent snapshot.

Select “Restore my snapshot” to restore it into our test MongoDB cluster.

Select the test upgrade cluster as the destination for the restore.

Now the automated restore into the test cluster will be performed. Depending on the size of the data files being restored, this operation could take some time.

Automated restore into test cluster

After the restore finishes, we’ll see the following:

Test cluster restore complete

4. Upgrade the test upgrade cluster from MongoDB 3.2 to MongoDB 3.4

Now we can initiate our testing procedures to understand the implications at the application tier during the online upgrade process. To perform the upgrade, we’ll select “Configuration” on the new test cluster which we’ve just restored our backup into:

New test cluster configuration

Next, we’ll click “Change version” and select “MongoDB 3.4 with WiredTiger”

Test cluster 3.4 upgrade

After selecting MongoDB 3.4, we’ll see the important notice that downgrading from MongoDB 3.4 to 3.2 will not be possible. This is one of the reasons why performing a test cluster upgrade is highly recommended.

Cluster 3.4 upgrade

After deploying we’ll see the blue bar during the upgrade:

Cluster 3.4 deployment - blue part appears

And quickly we’ll have an upgraded cluster running on MongoDB 3.4:

Upgraded cluster running on MongoDB 3.4

5. Execute our test suite against the MongoDB 3.4 test upgrade cluster.

We will go ahead and confirm connectivity of all of the clients that utilize our cluster and put the new cluster through our entire test and performance suite if it wasn't already running since before initiating the upgrade.

Test suite against MongoDB 3.4 test upgrade cluster

We’ll either confirm that we’re ready for MongoDB 3.4, or potentially unearth areas for tuning or necessary driver upgrades, depending on our usage.

6. If our tests pass, we can upgrade our production cluster to MongoDB 3.4 and terminate our test cluster.

We’ll click “Configure” on our production cluster

Configure production cluster

Because MongoDB Atlas is built on replica sets, the upgrade process performs a rolling restart of the cluster. As a result, the production application remains available and online.

And we can terminate our test cluster if we no longer want to maintain it for testing.

Next steps

If you’re an existing MongoDB Atlas user on MongoDB 3.2, we encourage you to review compatibility changes in MongoDB 3.4 and the full release notes.

You can then follow the process outlined above to restore a backup to a new cluster and upgrade it to MongoDB 3.4.

If you’re new to MongoDB Atlas, you can easily deploy your first MongoDB 3.4 cluster:

Just click the "Build a new cluster" button.

Then select MongoDB 3.4 in the build cluster form.

Deploy MongoDB 3.4 cluster

Previous Article
Travellers Instantly Browse Billions of Recommendations With MongoDB-Powered New Amadeus Flight Search Portfolio
Travellers Instantly Browse Billions of Recommendations With MongoDB-Powered New Amadeus Flight Search Portfolio

I’ve got $600 and I want to escape to somewhere warm for winter – where can I go? Answering that question e...

Next Article
Upstate Hacks 2016 Postmortem - MyCart
Upstate Hacks 2016 Postmortem - MyCart

This is a guest post from one of our community members, Declan Hopkins. This past October marked the 8th in...