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.
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”
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.
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
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
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
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
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
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
43.
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.
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