Operations Best Practices Part 3: Deploying MongoDB with Confidence

(Topics included: Security, HA (journaling, replication) and durability, backup)

Welcome to our multi-part series on operations best practices. This last post in the series covers what you need to know to prepare for a secure and highly available MongoDB deployment. Download the MongoDB Operations Best Practices guide to learn more.

Blog Series:

1. Laying the Groundwork for MongoDB High Performance
2. Managing MongoDB
3. Deploying MongoDB with Confidence

Securing your MongoDB deployment

Running a secure application is an important aspect of any MongoDB deployment. While there is no way to completely eliminate risk, there are best practices to follow for securing your MongoDB deployment.

We recommend following a Defense in Depth approach [see the NSA definition] which is to layer your environment to prevent the potential of any one single point of failure that would allow unauthorized access to data stored in a MongoDB database.

To reduce your security risk, consider the following measures:

• Running MongoDB in a trusted environment
• Limiting access to the database
• Following a system of least privileges
• Instituting a secure development lifecycle
• Following deployment best practices

MongoDB Enterprise offers advanced security features with Kerberos and LDAP authentication, Red Hat Identity Management Certification, and auditing. In addition to MongoDB’s already comprehensive security framework – which includes Role-Based Access Control, PKI certificates, SSL and Field-Level Redaction – MongoDB Enterprise includes advanced features such as user rights management, auditing, encryption, and administrative controls. Download the MongoDB Security Architecture white paper for additional details on these security features.

Reference our Security Checklist documentation for an extensive checklist of security measures to protect your MongoDB installation.

Deploying for high availability

Making sure your data is durable and your database is highly available in MongoDB is essential for any high performing application. MongoDB supports continuous operation through replication providing redundancy and self-healing recovery. With MongoDB, you should use replica sets to maintain copies of your data in order to prevent database downtime. Replica failover is fully automated in MongoDB so you don’t need to manually intervene in case of failure.

There is much to know about MongoDB replication features and you can find out more in our Replication documentation. A few helpful considerations when planning your replication architecture include:

• You can configure the number of replica nodes in a replica set. Having a large number of replica nodes gives you increased protection against downtime in the event of multiple machine failures.
• You should deploy replica sets across multiple data centers to avoid downtime in the case of regional disaster (such as a fire, flood, hurricane).
• Make sure that your replica set members will always be able to elect a primary replica set member. To do this, run an odd number of replica set members. Not each has to be a data-bearing node. You can for example configure a lightweight arbiter process which is able to vote in elections.
• When you have geographically distributed members, you should know where the majority of replica set members will be located in case of any network partitions. Try to make sure that the set can elect a primary among the members in the primary data center.
• Consider including a hidden member in the replica set. They are useful for live backups or running applications that need to be isolated from regular operational workloads – for example, analytics.

Administrators of MongoDB can specify the level of availability when issuing writes to the database, also known as write concerns. Reference the Write Concern for Replica Sets documentation for more detail.

You have several options when configuring write concerns on a per connection, per database, per collection or per operation basis.

• Write acknowledged is the default global write concern.
• Replica safe. MongoDB supports writing to a specific number of replicas or to a majority. Ensuring writes propagate to additional replicas is an advantage of distributed databases, providing you with a richer set of durability guarantees than a conventional relational database .
• Journal safe. The mongod process will confirm the write operation to the application only after it has flushed the operation to the journal on the primary.
• Data center awareness. You can create sophisticated policies in terms of how writes are to be written to data centers. Our Data Center Awareness documentation has additional information on this topic.

To ensure strong consistency, reading from the primary replica set member is the default but you have many options for configuring reads. You could configure reads to be routed to secondary replica set members in the event that the primary is unavailable, thereby maintaining continuous query operations for your applications. You could direct reads to only be serviced by nodes that are geographically closest to the client – thus improving customer experience by eliminating lengthy network hops You can learn more about this topic by referencing our Read Preferences documentation.

Journaling is an important part of your disaster recovery strategy. MongoDB supports write-ahead journaling of operations to help with fast crash recovery in the case of a failure. In the event of an outage, journal entries are automatically recovered. We encourage you to read through the detailed documentation on Journaling to learn more.

Developing a sound backup and recovery strategy

You hope it never happens but disaster can strike your data center in the form of a fire, flood or human error. Administrators of MongoDB can restore operations without data loss by having a comprehensive and tested backup and recovery strategy in place.

You can backup a MongoDB system with Ops Manager, available with Enterprise Advanced, or with the cloud-hosted MongoDB Management System (MMS). Both offer point-in-time backup of replica sets and cluster-wide snapshots of sharded clusters. This allows you to restore your system to the precise moment you need.

There are also other options to backup your MongoDB system: File system backups or using the mongodump tool packaged with MongoDB. File system backups allow you to create a consistent snapshot of the file system. The documentation on Backup and Restore with Filesystem Snapshots offers more details on this method. mongodump performs a live backup of the data in MongoDB and can be used to dump an entire database, collection or result of a query. You can then use the mongorestore utility to restore the data to a new or existing database in case of a disaster.

There are many resources to help you get started on adopting operations best practices. Read the past blog posts in this series, including Part 1 on high performance and Part 2 on managing MongoDB. Have a look at the plethora of resources on our website: from the webinar archives to conference presentations. And if you’re interested in taking classes to learn more, sign up for our free operations and advanced operations online courses on MongoDB University.

And if you haven’t already, download our best practices guide learn more about operations.

DOWNLOAD OPS BEST PRACTICE

<< Read Part 2

About the Author - Pam

Pam is a product marketer with over a decade of experience leading marketing programs for B2B technology products. Before MongoDB, she worked at DoubleClick, the ad serving platform company, and then at Google where she worked on marketing display advertising products for over 5 years. Pam earned her BA in History from Barnard College and an MBA from Duke University.