- The MongoDB Management Service (MMS) provides monitoring, backup, and automation capabilities for MongoDB deployments. - MMS monitors deployments through agents that identify server configurations, collect performance metrics, and enable alerts. It provides topology views and charting of key indicators. - MMS backups MongoDB data by taking snapshots of replica sets and clusters. It stores backups for up to one year and allows point-in-time restores. Restoring a backup is simple and speeds up tasks like launching QA environments. - MMS automates backups without much overhead. It provides a consistent way to backup sharded clusters through checkpoint restores with a small restoration window.

1. MongoDB Backup and
Monitoring with MMS
Sam Weaver, Senior Solution Architect
#MongoDBWorld

2. Operational complexities

3. What is MMS?

4. What is MMS?

5. The MMS User Interface
Navigation tabs take you to the different functional areas of MongoDB
Management Service. Through this interface, you can monitor your
deployment, configure alerts via email or SMS, backup your data and
automate your deployments.

6. Monitoring

7. Monitoring
MMS monitors deployments through a monitoring agent
installed on a host server. One agent can:
• Identify the members of the deployment and server
configuration, MongoDB Version, query profile, logs, etc.
• Dynamically create a graphical representation of the
deployment technology.
• Visualize performance indications like lock percentage,
reads/writes, queues, etc.
• Enable you to configure alerts for when these numbers
aren’t “normal”

8. Topology view

9. Charting

10. Alerting

11. • Set a base line for normal by seeing how your
production environment responds to regular
traffic
• Check for spikes in operations – peak or
unexpected load?
What’s “normal”?

12. =
Key performance indicators
• Page faults, queues and lock % may be
indicators that you need to scale up or out
• Oplog window indicates how long a
secondary can be behind the primary
• Background average flush indicates if your
disks are struggling

13. Monitoring
Additionally, MongoDB offers Proactive Support for
Subscription Customers, where our engineers are able to
monitor your deployment and make suggestions in order to
tweak for better performance or avoid doom.

14. Backup

15. Disasters are not only due to user error...

16. There’s many other causes of disasters

17. 34% of companies fail to test their
tape backups

18. 77% of those that did, found failures

19. 60% of companies that lost their data…

20. Closed business within 6 months

21. 140,000 HDD crashes per week in the US

22. 93% of those who lost their DC for 10
days…

23. Filed for bankruptcy within 1 year

24. Risks Are All Around
• Risks
– Storage failure
– Power outage
– Programmer error
– Hardware failure
– Data center failure
– Cyber attack
– Weather related incidents

25. • Relative to any particular risk
– How much data can you afford to lose? (RPO)
– How long can you afford to be offline? (RTO)
– What price are you willing to pay to remove the risk?
• MongoDB Solutions
– Replication
– Application and Infrastructure engineering
– Backup of your Data
Analyzing your Risk Tolerance

26. Our Recommendations for
Avoiding Risk

27. Solution 1: Replication
• Built into MongoDB, only ops and
infrastructure cost
• Tunable durability gives you very little to zero
risk in case of failure
• Down for a very short interval
• BUT… programmer errors will replicate
almost instantly

28. Solution 2: Application and
Infrastructure Engineering
Lots of potential solutions to ensure
redundancy in applications and their
infrastructure, such as:
• Having more than one data center
• Spreading across AWS zones

29. Solution 3: Backup Your Data
Backup of your data is one way to assure
availability and lower risk. Keep in mind,
backups:
• Can suffer from being out of date
• Can be slow
• Isolated
• ...but usually cheap and covers most risks

30. • mongodump/mongorestore
• Storage level options
• MongoDB Backup Service
Comparing MongoDB Backup
Approaches

31. • Can be run online or offline
• Oplog aware for point in time restores
• Filter in, filter out
• Considerations:
– Data size
– Sharding
Mongodump/MongoRestore

32. • Copy files in your data directory (e.g.
/data/db)
• File system or block storage snapshots
• Fastest way to backup/restore
• Considerations:
– Journal
– Consistency
– Backup granularity (whole file system back up?)
– Ops expertise
– Storage of snapshots or data file backups
Storage-level Backups

33. ● Possible in the cloud (via
mms.mongodb.com) or in your own hosted
environment
● Available on a variety of operating systems
(Examples - RHEL, Ubuntu, CentOS, OS X,
Windows)
Backup with MongoDB Management
Service

34. Mongodump File system MMS Backup
Initial complexity Medium High Low
Confidence in Backups Medium Medium High
Point in time recovery
of replica set
Sort of ☺ No Yes
System Overhead High Can be low Low
Scalable No With work Yes
Consistent Snapshot of
Sharded System
Difficult Difficult Yes
MongoDB Backup Recovery
Approaches

35. MongoDB Backup with MMS
How it Works

36. • Access the MMS UI
• Install the Backup Agent onto one server
• Select the replica sets or cluster you want to
back up
• Click the Start button
Backup with MongoDB Management
Service

37. System Architecture

38. The Web Interface

39. Backup is Highly Configurable
Select which:
• Replica Sets to include/exclude
• Collections/namespaces to include/exclude
• How often snapshots are taken of your data
(down to 15 minute intervals)
• How long your data is stored (up to 1 year)

40. • From the initial sync, we rebuild your data in
our datacenters and take a snapshot
• We take snapshots every 6 hours
• Oplog is stored for 24 hours
Under the Hood

41. Snapshots page

42. Restore from a Snapshot
Restoring data is incredibly simple -
• Select the snapshot you’d like to restore and
choose a delivery method (SCP push or HTTPS
pull)
• Receive the file
• Unzip it
• Point your mongod to this directory

44. Restoring a MongoDB Sharded
Cluster
Restoring data is only a few extra steps
• Select your cluster in the MMS UI
• Restore from a pre-build snapshot or request a
checkpoint restore (15 minute window)
• You will receive one data file to download for
each shard, and one for the config server(s)
• Follow the same process as before for moving
the data files to the server

45. How Do We Backup a Sharded
Cluster?
• Behind the scenes:
– Balancer paused every 6 hours**
– A no-op token is inserted across all shards,
mongoses and config servers
– Oplog applied to replica sets until point at which
token was inserted
• Provides a consistent state of database across
shards
**The balancer can be paused more frequently to accommodate more frequent restore points.

46. Small Deployment

47. Deploy for Redundancy

48. Recap: MongoDB Backup with MMS
• Simplest means of backing up your database
• Peace of mind, it just works
• Point-in-time restores for replica sets
• Check point restores for clusters
• Spin up QA or reporting environments quickly
from snapshots

49. Resources
• MMS Cloud mms.mongodb.com
• MMS Cloud Documentation
mms.mongodb.com/help/
• MMS On-Prem Documentation
mms.mongodb.com/help-hosted/
• MMS On-Prem software download
available on the subscription downloads
page

50. Questions?

51. Thanks!
Sam Weaver, Senior Solution Architect