Navigation

Ops Manager Overview

MongoDB Ops Manager can automate, monitor, and back up your MongoDB infrastructure.

Automation

Ops Manager Automation enables you to configure and maintain MongoDB nodes and clusters.

"Automation coordinates MongoDB instances running in a public cloud, in your private data center, or on your local system."

MongoDB Agents using Automation on each MongoDB host can maintain your MongoDB deployments. You can install the MongoDB Agent. Automation can add hosts and deploy and upgrade new or existing clusters.

Monitoring

Ops Manager Monitoring provides real-time reporting, visualization, and alerting on key database and hardware indicators.

How Monitoring Works

When you activate Monitoring on a MongoDB host, Monitoring collects statistics from the nodes in your MongoDB deployment. The Agent transmits database statistics back to Ops Manager to report deployment status in real time. You can set alerts on indicators you choose.

Backup

Ops Manager Backup provides scheduled snapshots and point-in-time recovery of your MongoDB replica sets and sharded clusters.

How Backup Works

When you activate Backup for a MongoDB deployment, Backup takes snapshots of data from the MongoDB processes you have specified.

Note

Only sharded clusters or replica sets can be backed up. To back up a standalone mongod process, you must first convert it to a single-member replica set.

Backup Workflow

When you start backing up a MongoDB deployment, Backup performs an initial sync of the deployment’s data as if it were creating a new, “invisible” member of a replica set. For a sharded cluster, the Agent syncs each shard’s primary member and each config server. The Agent sends the initial sync and oplog data over HTTPS back to Ops Manager.

The Backup then tails each replica set’s oplog to maintain on disk a standalone database, called a head database. Ops Manager maintains one head database for each backed-up replica set. The head database is consistent with the original primary up to the last oplog supplied by the agent.

Backup executes the initial sync and the tailing of the oplog using standard MongoDB queries. The cluster being backed up is unaware of the additional copy of the backup data.

Backup uses a MongoDB instance version equal to or greater than the version of the replica set it backs up.

Backup takes and stores snapshots based on a user-defined snapshot retention policy. Sharded cluster snapshots temporarily stop the balancer so that they can insert a marker token into all shards and config servers in the cluster. Ops Manager takes a snapshot when the marker tokens appear in the snapshot data.

The procedures used to reduce the storage space required to store a snapshot depend on where it is stored:

Snapshot Store Description
MongoDB blockstore Only the differences of each successive snapshot are stored. Compression and block-level deduplication reduce the size of snapshot data.
AWS S3 bucket Only the differences of each successive snapshot are stored. Compression and block-level deduplication reduce the size of snapshot data.
File system store Depending on the configuration, compression reduces the size of the snapshot data.

All snapshots represent a full backup.

To learn more about how to configure backups, see Backup Configuration Options.

Restore Data

Backup can restore data from a complete scheduled snapshot or from a selected point between snapshots.

When you restore from a snapshot, Ops Manager reads directly from the snapshot storage and you can download the snapshot files from an HTTPS link.

When you restore from a checkpoint or point in time, Ops Manager first restores a full snapshot from the snapshot storage and then applies stored oplogs until the specified point is reached. Ops Manager delivers the snapshot and oplog updates using the same HTTPS mechanisms. To enable checkpoints, see Enable Cluster Checkpoints.

You can configure how much of the oplog you want to keep per backup. This affects how much time a checkpoint and point-in-time restore can cover.

Server Pool

Server Pools deprecated as of Ops Manager 4.0

As of Ops Manager 4.0, server pools are deprecated and disabled by default.

Ops Manager Server Pool allows Ops Manager users with administrative privileges, i.e. Ops Manager Administrators, to maintain a pool of provisioned servers that already have Automations installed. When users in a project want to create a new MongoDB deployment, they can request servers from this pool to host the MongoDB deployment.

For details, see Provision Servers for the Server Pool.