We’ve made several major improvements and bug fixes to the MongoDB Backup Agent used by MMS, including:
- More granular restore points for sharded clusters
- Support for the latest version of MongoDB, version 2.6
- Improved packaging with service scripts to make deployment easier
- SSL connectivity improvements, resulting in fewer connection resets and hangs
- Fixed a file descriptor resource leak
We encourage all backup users to upgrade to the latest agent version for a better overall experience with the service.
To access these improvements, please download the agent from the MongoDB Management Service by going to Settings > Backup Agent.
Don’t Let Your MongoDB Standalone Stand Alone: How to Back Up a MongoDB Single Server
Lots of people start with standalone servers when they first try MongoDB. If you are running standalone, it’s especially critical that you back it up because you don’t have the fault tolerance and redundancy of a multi-node replica set. MongoDB Management Service (MMS) requires that you run a replica set in order to back up. What is not widely known is that you can run a one node replica set, thereby producing the oplog that MMS Backup requires to work, while still running only a single mongod server. Here is how you do it. Shut down the standalone mongod instance. The safe way do this is by calling db.shutdownServer() from the mongo shell. Restart the instance. Use the –replSet option to specify the name of the new replica set. Connect to the mongod instance. Use rs.initiate() to initiate the new replica set. Here is a concrete example. If you your database is running on the standard ports and uses the standard location for the data directory (/data/db) then you might issue the following command to start the server: # mongod --replSet rs0 You can name the replica set however you like. Using “rs0” was just an example. After you do this, initiate the replica set: # mongo # rs.initiate() You now have a replica set! If you need more detailed instructions, you can visit the docs . Now that your single server is a one-node replica set, you can configure backup through MMS Backup. 1) Get Monitoring Running Using MMS Monitoring is prerequisite of using MMS Backup because the backup service relies on the configuration information gathered by the monitoring service to figure out what to backup. Monitoring is free. If you are not already monitoring your server using MMS Monitoring, go to mms.mongodb.com and signup for a free account. You will then need to download the monitoring agent and run it on a machine that can see your server. 2) Register for Backup Visit the Backup tab within MMS to register for the service. This includes setting up two-factor authentication for restores, entering your credit card for billing and accepting the terms of service. 3) Install the Agent The next step is installing the backup agent on your deployment. This step is easy - just download the appropriate agent for your operating system from the Settings section of mms.mongodb.com and unzip or untar the file in the preferred directory. In the backup-agent directory, issue the following command to start the agent (unix variant): # ./backup-agent 4) Start Your Sync Now that you’ve got replica sets going and the backup agent installed, the final step is to go the backups page on the MMS UI and enable your one-node replica set for backup. 5) Rest Easy - Your Standalone Server is No Longer Standing Alone - It’s Backed Up! An initial sync will begin, and soon your database server will be backed up to MongoDB’s datacenters. Start backing up now. Create an MMS account!
Considering NoSQL? Let's Break Down Your Options
Non-relational alternatives to relational databases — usually referred to as NoSQL databases — have been rapidly gaining popularity over the past decade. In 2013, MongoDB published one of our most popular white papers, “Top 5 Considerations When Evaluating NoSQL Databases.” We have since updated that paper as the technology has evolved. MongoDB is now offering a major update, which adds two new issues organizations should include in their thinking: how a database handles data generated at the edge by mobile devices and how a database fits into a broader data platform that includes search and analytics. If you’re testing the waters of NoSQL databases, then you’re probably familiar with how they’re different from traditional relational databases. The list of things you already know about NoSQL probably looks something like this: They use a different data model and query language. They have dynamic schemas. They scale horizontally. Beyond those common features, there are significant differences among NoSQL databases. The seven areas of significant differences among your options are: Data model (document, graph, key-value, etc.) Query model Consistency and transactional model APIs Mobile data Data platform Commercial support, community strength, and lock-in From MongoDB’s point of view, the most important consideration is the data model. We popularized the document model , which supports a superset of all data models, making it useful for a wide variety of applications. Key features include the ability to index and query in any field, and the natural mapping of document data structures to objects in modern programming languages. Recent shifts in how modern applications are developed and deployed — and in the experiences they offer customers — highlight the two new considerations. Mobile use cases: Mobile applications introduce the added challenge of not always being connected to the network. Developers need a solution for keeping all their customers’ apps in sync with the back-end database, no matter where they are in the world and what kind of network connection they have. The solution also needs to scale easily and quickly as more users download an app, and support the cutting edge of mobile development technologies as they evolve. Data platform: MongoDB’s application data platform provides developers a unified interface to serve transactional and operational applications alongside search, real-time, and data lake application needs. It eliminates the overhead and friction of developers having to stitch together multiple discrete technologies into a complex architecture, each creating its own duplicated data silo — connected by fragile ETL pipelines — and accessed, secured, governed, and operationalized by different APIs and tools. For a deep dive into all the differences among NoSQL databases, download our white paper, “ Top 7 Considerations When Evaluating NoSQL Databases .”