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:
- Spin up a test environment from a backup
- Upgrade the test environment from MongoDB 3.2 to MongoDB 3.4
- Confirm that your testing and performance suite pass on MongoDB 3.4
Specifically, in this tutorial we’re going to:
- Start with a production MongoDB Atlas cluster (“Cluster0”) running MongoDB 3.2 with the Atlas backup service enabled.
- Spin up a new MongoDB Atlas test cluster, initially on MongoDB 3.2, (“cluster34upgrade”) with sufficient storage to restore the production cluster’s backup.
- Restore the most recent backup snapshot from the production cluster into the test cluster.
- Upgrade the test cluster from MongoDB 3.2 to MongoDB 3.4
- Execute our test suite against the MongoDB 3.4 test cluster.
- 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.
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.
After the cluster deploys, we’ll see the following:
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.
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.
After the restore finishes, we’ll see the following:
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:
Next, we’ll click “Change version” and select “MongoDB 3.4 with WiredTiger”
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.
After deploying we’ll see the blue bar during the upgrade:
And quickly we’ll have an 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.
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
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.
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.