Are you ready for production?
Are you ready for production?
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
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 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 MongoDB 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. Set up MMS Monitoring and Alerts
While there are a great number of monitoring solutions on the market, all of MongoLab’s Replica Set cluster plans are integrated with MongoDB’s MMS Monitoring system for database monitoring and alerting. MMS Monitoring is a service designed to give both current and historical insight into your cluster’s health and performance, capturing all the database and host-level metrics you need to understand what is happening inside your deployment. MMS is crucial in diagnosing performance issues and capacity planning for future growth. We highly recommend that you leverage MMS in both development and production.
You can follow the directions in our support page to set up MMS properly on your MongoLab account.
5. 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.
6. 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.
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!
Published at DZone with permission of Chris Chang , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.