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

Andrew Davidson
December 5, 2016 | Updated: December 8, 2016
#Cloud

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.

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

Upstate Hacks 2016 Postmortem - MyCart

This is a guest post from one of our community members, Declan Hopkins . This past October marked the 8th installment of the bi-annual Hack Upstate, a hackathon where developers, designers, and innovators from Upstate New York come together to build some seriously awesome stuff. I attended with my team member and friend, Arthur , and we took home a prize for the best usage of MongoDB, awarded to us by MongoDB’s very own Peter Gravelle. Our weekend hack was a bit of an experiment with barcode scanning, facial recognition, and how many APIs we could cram into a single project during 24 hours. The end result was MyCart , a smart and simple point of sale solution that allows vendors to use a central database to manage their products and eliminates the need for a cashier and/or cash register. A vendor logs onto the enterprise screen of the app, scans the products that they wish to have available for sale, and then switches the app back to a consumer mode. In this mode, customers in the shop can take items that they wish to purchase, scan them, and then check out when they are ready. Sounds a lot like a self-checkout station, doesn’t it? Many stores have that. The innovative portion of the app kicks in after checkout has been completed. The point of sale station (most likely an iPad) snaps a picture of the customer, and then uses facial recognition technology to identify the shopper. This information can then be used to show analytics and statistics on certain purchases, which the vendor can use to improve their business. For example, say that after a business day, you check on your analytics and you find that an item is being purchased primarily by customers in a younger age range. It might be a good idea to move that item in the store so it is grouped with other items being purchased by the same age range, to possibly increase sales. The data can also be used to improve the customer experience. We used Swift for the iOS app, Python for the backend, and MongoDB for our database, and I think it was a great tech stack to work with. Regardless of some issues getting Python and MongoDB to interface properly, it was really simple to get a database up and running, and fill it with products. Unfortunately, we didn’t get to entirely finish the app. What Went Right Planning. We came up with the idea very quickly after the hackathon began, and even got a room with a whiteboard that allowed us to sketch out details easily. Design. Arthur is pretty rad at design, so we were able to make the prototype of the app look nice without losing much time. Motivation. I’m a really competitive person, and we were motivated to win. We didn’t want to go home empty handed. This drive helped us stick with the project until the minute our 24 hours were up. What Went Wrong Hardware. We spent hours trying to fix a non-existent bug with the barcode scanning, only to find out that the “bug” was caused because the iPad 2 just has a really bad camera. Python, PyMongo, and Flask. These three would have been easier to use if I had any experience with python, but I had to learn python on the fly for this project. I was running into all sorts of errors deserializing MongoDB objects into JSON, but eventually I figured out a hack to make it work properly. The demo. During our demo, I accidentally ran the server on the wrong port, and the app just didn’t work at all. Luckily, the folks at Hack Upstate allowed us to do another demo after I let them know that I found the issue. Sleep. We worked into the wee hours of the morning on the app, and eventually I started feeling quite sick. I had to sleep it off, and we lost about 6 hours. Because of this, we didn’t get to finish implementing the facial recognition API. Overall, regardless of the app’s faults, and the features we didn’t get a chance to fully implement, I’m proud of it. I'll take what I've learned over that weekend and use it to do even better next time. Upcoming MongoDB Events About the Author - Declan Hopkins Declan is a software developer and entrepreneur who is always looking for new opportunities to learn and drive the industry forward. You can learn more about him and his projects, as well as read his blog, at www.declanhopkins.com

December 2, 2016

Next →

Using MongoDB Skill Scanner to Build Better Training Programs

Technology leaders know that transformation is about more than just adopting modern technologies like MongoDB. The entire organization has to rally behind change — which is no easy task. The skills that modern development teams need are evolving faster than ever, and hiring to fill skills gaps can be too time-consuming and expensive of a process for many organizations. So it’s imperative that we plan for how we want to bring our people with us on our modernization journey, and proactively upskill them on the technologies we’re betting on. Because what happens if you choose MongoDB, but your developers don’t know how to use it? CIOs know that training programs are easier said than done. EY reported that 30% of CIOs acknowledge that their training programs are ineffective, and that they’re struggling to retain talent because of it. These leaders come to us to help them build and execute their MongoDB training programs , and seek advice on two extremely common yet critical challenges: How do we get away from the less effective one-size-fits-all approach? How do we measure the ROI of our training program and connect it to business impact? How we use MongoDB Skill Scanner to overcome training challenges Our Professional Services team uses a tool called MongoDB Skill Scanner to address both of these challenges. This tool helps us provide these three benefits to our customers looking to build a training program: Improve MongoDB proficiency: Teams can use Skill Scanner to quickly and easily assess the MongoDB skill gaps of their team members and gain a comprehensive understanding of their team’s MongoDB skills baseline. Increased productivity and accuracy: When team members have a comprehensive understanding of MongoDB, they are able to work more quickly and accurately on projects, leading to increased productivity and a higher quality of work. Save time and money with targeted Training: Using Skill Scanner, customers can avoid wasting time and money on trial-and-error learning. Instead, they can focus on improving their skills in a more targeted and efficient way with right-sized training plans. By leveraging this data, our customers’ engineers can engage in the right training at the right time, targeted for their job role and specific skill shortages. When a training program is built this way, engineers maximize their knowledge retention and minimize time away from their projects. Skill Scanner includes three role-based assessments, one for developers, database administrators, and DevOps respectively. Through a series of multiple choice questions, Skill Scanner provides customers with a clear understanding of their level of expertise across a set of technical skills that are critical for success in their role. After submitting the assessment, engineers will get results in each skill area outlining if they are beginner, intermediate, or advanced. Why data-driven training programs matter We’ve learned that it’s not enough to just tell teams to go watch training videos or webinars on their own, or to place everyone in the same one-size-fits-all program. Skills gaps vary from team to team, and individual to individual. The one-size-fits-all approach of some programs may not address individual learners' needs, wasting time and making it difficult for them to acquire new skills. By using Skill Scanner, we’re able to interpret this data to help determine which training courses your team should take. But we don’t only capture this data before doing training; we use Skill Scanner again after training programs are completed to see where immediate improvements have been made. This helps technology leaders prove the impact and ROI of their training, and gives them the confidence that their teams are ready to be successful with MongoDB. Developing a Precision Learning Program To go even further, our team can work with you to build a Precision Learning Program, where we use Skill Scanner data to build learning schedules that are unique to each individual. These schedules include a variety of short, blended, learning events such as classes, technical workshops, self-paced exercises, and project coaching. We’ve seen PLP lead to higher knowledge retention and of course, measurable project results. A customer who recently concluded their PLP saw a 43% increase in knowledge retention. Getting started building a personalized training program Skill gaps aren’t a novel problem IT leaders are facing. But with new digital courses, training, and technologies, the resources to close these gaps are at your fingertips. Skill Scanner and Precision Learning Program have been specifically designed to empower teams by offering targeted training that enhances their understanding of MongoDB. These short training events are carefully crafted to close skill gaps without compromising developer productivity. We’ve seen a variety of customers use this tool to help train their team’s individual needs, from needing to upskill new hires on their teams, projects with new MongoDB products, migrating to MongoDB Atlas, and more. It also saves your business the hours developers would've wasted searching for answers (and developers don’t want to spend their time that way, either). “We need help getting from point A to point B and feel MongoDB is uniquely positioned to help” — CTO at large insurance firm If you're interested in trying out MongoDB Skill Scanner or want to explore the MongoDB Precision Learning Program further, you can reach out to your account representative or contact us directly .

June 7, 2023