Are you ready for production?

Updated article on 03/24/15

Transitioning your application from development to production is a monumental step. Over the years, we at MongoLab have acquired a lot of valuable experience helping our customers successfully manage their production-grade MongoDB deployments.

What follows is a checklist of action items that we've found imperative for successfully taking your application to production. For the experienced, we hope you can use this guide as a refresher on best practices. For the newer folks, this is a must-read on how to ready your database for the big move.

1. Use Replica Set clusters for high-availability

Hardware and software failure are a reality. While it is perfectly fine to develop your application on a single-node database, to do so in production is ill-advised. Your users expect to always have access to your application and even the smallest windows of downtime may result in lost opportunities. You need to make sure your database can withstand node failure.

MongoDB Replica Sets synchronize data over multiple redundant servers and protect your application from downtime in the face of node failure. Should your primary node should fail or become unreachable, your application will automatically failover to a secondary node, ensuring the availability of your application.

Before you deploy your application to production, it is crucial to test that your application is properly configured to gracefully handle the failover process.

First, confirm that you are using your driver properly for Replica Set connections. In every native 10gen driver, the MongoClient is the official class used to create connections to MongoDB instances. There are also many options for connection configurations, so you will want to familiarize yourself with your native driver's implementation and pick options best for your environment and network. If you're unsure, be sure to email us- we're happy to help!

Second, study and understand the failover process. Our free flip-flop service is a demonstration and experimentation tool that will really help you understand the Replica Set election process. Once you grasp the mechanics behind the process and are ready to test on your cluster, you can navigate into your cluster in our management UI and call 'replSetStepDown' (under the "Tools" tab). This will force your primary to step down and your secondary to be elected as the new primary. If your application can handle this transition seamlessly, give yourself a pat on the back!

2. Schedule regular backups

While multi-node replication can offer redundancy to protect against system failure, it will not protect you from accidents caused by human error such as dropping a collection, or even your database. Backups are crucial for ensuring that you do not lose valuable data. There are many strategies for backing up your MongoDB database. If you are using MongoLab, our backup system makes it very easy to create custom backup plans, allowing you to define your own schedule, retention policy, and storage location (e.g. MongoLab's own cloud storage or your own Amazon S3 container).

3. Build the right indexes

Based on our experience, improper or lack of indexing is the number one reason for poor database performance. While your application might seem fast in development, the lack of proper indexes will show when your collections grow from dozens to millions of documents. Before you go to production, you must make sure you have the right indexes.

In order to assist fellow Mongoers, we've written a few blog posts regarding best indexing practices:

This last link to Dex, our open-source index recommendation tool, is crucial. Dex can watch your queries and tell you which indexes you are missing. Use it!

Finally, always consider whether you want to build your indexes in the background or foreground. While building them in the foreground is faster, the build blocks all other operations to the database. On a production system, you almost always want to build your indexes in the background to minimally impact your live database.

4. Host your application and database in the same datacenter

To maximize overall performance, we strongly recommend that you host your application and database in the same datacenter. Configuring your two layers to be on the same network allows packets to travel shorter distances, resulting in many benefits such as: faster speeds, lower latency, fewer network blips, and improved security.

5. Bolster your security

Hosting your application and your database in the same cloud will not only yield better performance, but will also improve security. All major cloud providers prevent virtual machines (VMs) from sniffing packets intended for other VMs, so locating your application and database on the same internal network reduces the number of openings for malicious activity to take place.

Be mindful to secure your database credentials in config files on your application servers (and not checked into GitHub...), and use strong passwords. All MongoLab databases are run in 'auth mode', requiring all connections to authenticate with valid credentials, but it is up to you to keep those credentials private and hard to guess.

For additional security, you will want to firewall your database so that only your application infrastructure can connect to your server, regardless of who might gain access to your database credentials. MongoLab allows for custom firewalls on all of its Dedicated plans.

Wrapping Up

By thinking critically about these topics and following the steps in this guide, you will be off to a great start and can feel confident moving to production. As always, feel free to email the team with any questions you have along the way!

 In Mongo,


, , , , , , ,