Docs Menu

Docs HomeMongoDB Ops Manager

Install the Ops Manager Application Database and Backup Database

On this page

  • Considerations
  • Prerequisites
  • Deploy Backing Databases
  • Next Steps

Before you install Ops Manager, you must deploy its supporting databases. These are called backing databases. These databases include the Ops Manager Application Database and the backup database. The following table compares the Ops Manager Application Database and the Backup Database:

Frequently Asked Questions
What does the database store?

Warning

The following items can contain sensitive data. To prevent unauthorized access and protect sensitive data, you must secure the Ops Manager Application Database.

  • Ops Manager operational data.

  • MongoDB database logs that you can retrieve and view using Ops Manager.

  • Unoptimized queries if you enabled Performance Advisor, which analyzes logs to recommend performance improvements in the Monitor and Improve Slow Queries page.

  • Real-time metrics if you enabled Real Time Performance Panel, which collects and displays real time metrics from your MongoDB databases in the Real Time Metrics page. Ops Manager deletes the data when you navigate away from the Real Time Metrics page.

  • Oplog data

  • Temporary sync data

  • Your snapshots, depending on your configuration

Is the database necessary?
Yes
No, unless you use Ops Manager to backup the databases that Ops Manager manages.
How should the database store the data?
Dedicated replica set on independent storage volume
Dedicated replica set per backup database on independent storage volumes
Can the database use more than one deployment?
No
Can Ops Manager use the Automation module with this database?
No
Yes
Can Ops Manager use the Backup Module to back up this database?
No
No
Can Ops Manager use the Monitoring module to monitor this database?
Yes

Note

Each backing database must use a dedicated replica set. The replica set can't store other data.

Running regular backups, a backup database could fill a volume. If the application database cannot write to a volume, Ops Manager stops. Proper storage setup reduces the risk of Ops Manager failures.

Each backing database replica set should include three data-bearing members for high availability. If you lack storage capacity for three data-bearing members, the third member of a backing database may be an arbiter.

For the Ops Manager application database, you may run one member of the replica set on the same host as Ops Manager.

Important

Backing Databases with fewer than three data-bearing members

When writing to its backing databases, Ops Manager uses the Replica Acknowledged (w:2) write concern. This write concern reports a write as successful only after the primary and one secondary acknowledge that write. This means that if a backing database loses one of the two data-bearing members, MongoDB stops write operations.

You can choose to monitor the application database after you install Ops Manager.

To monitor your application database:

  1. Finish installing the backing databases.

  2. Install Ops Manager Application.

  3. Enable Monitoring for the application database.

    1. Install the MongoDB Agent on the application database hosts.

    2. Add the application database through the Ops Manager UI.

Tip

See also:

To follow the full procedure, see Enable Application Database Monitoring.

The replica sets that host the Ops Manager backing databases must:

The replica sets must store data to support Ops Manager metadata only. They must store no other data.

If you use S3-compatible storage for block or oplog storage, the backing database can store the metadata for the blocks and oplog.

For the following Ops Manager release series, you may run its backing databases on any of the following MongoDB versions:

Ops Manager Release
MongoDB 4.4
MongoDB 5.0
MongoDB 6.0
MongoDB 7.0
Ops Manager 7.0
Deprecated
Supported
Supported
Ops Manager 6.0
Deprecated
Supported
Supported

Note

A deprecated version still works with the corresponding Ops Manager release, but we will remove the support for this version in the next release. MongoDB Support recommends migrating to a supported version to avoid potential incompatibility issues.

To learn more, see MongoDB Legacy Support Policy and MongoDB Software Lifecycle Schedules for Ops Manager.

Version support covers the full release series from the first to the last release.

To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual.

Important

Only the MongoDB Ops Manager backing databases must meet this requirement. The MongoDB deployments that Ops Manager manages do not. For the minimum versions required for managed MongoDB deployments, see MongoDB Compatibility Matrix.

Use WiredTiger for the Ops Manager application database.

For backup database configuration options, see Backup Preparations.

Do not run the backing databases with the MongoDB --notablescan parameter set. When set, this parameter specifies that all queries must use indexes.

Ensure that connections from Ops Manager to your backing databases are secure. Configure these databases to accept connections from Ops Manager that only use TLS.

Limit access to your backing databases to specific MongoDB users using an authentication mechanism. To configure your backing databases to use authentication, see Configure Ops Manager to Authenticate with Application Databases.

Set these users to have the readWriteAnyDatabase and dbAdminAnyDatabase roles. If a backing database is a sharded cluster, add clusterAdmin, otherwise add clusterMonitor.

The hosts that run the replica sets must meet the following requirements for:

The hosts must meet Ops Manager Application Database Hardware Requirements or Backup Database Hardware Requirements depending on which database the host runs. If a host serves other Ops Manager components in addition to the database, you must sum the hardware requirements for each component to determine the requirements for the host.

The hosts must be configured according to the requirements given in the MongoDB Production Notes except where explicitly contradicted in this tutorial. The Production Notes include information on ulimits, NUMA, and other configuration options.

Use lowercase FQDNs. If you use uppercase characters, Ops Manager may fail to find your backing database. To learn more about naming hosts, see RFC 1178.

Host network security must allow the needed ports described in Firewall Configuration. The appropriate inbound and outbound firewall rules for each host must allow access to the required ports.

RHEL and CentOS 6 limit the maximum number of user processes to 1024. This overrides the general user process limit (ulimit -u) setting.

For the userid that runs Ops Manager (mongodb-mms by default), add soft and hard nproc (number of processes) entries to the /etc/security/limits.d/99-mongodb-nproc.conf user process configuration file. Use values that are larger than the RHEL 1024 user process limit.

mongodb-mms soft nproc 200000
mongodb-mms hard nproc 500000

If /etc/security/limits.d/99-mongodb-nproc.conf does not exist, create it. Use the contents of the /etc/security/limits.d/90-nproc.conf file as a template.

If the hosts are not configured to use the default MongoDB data or log paths or ports and are enforcing SELinux policies, update the SELinux policies before starting the backing databases.

To learn how to update the SELinux policy:

To deploy MongoDB replica sets to host the Ops Manager backing databases:

1

Your hosts must meet the Host Configuration requirements.

Important

Make sure you configure the MongoDB deployment for your backing databases according to the MongoDB Production Notes. If you do not, this MongoDB deployment may fail.

2

Follow the Install MongoDB procedure in the MongoDB manual. If you choose to install MongoDB Enterprise for the backing database, you must install the MongoDB Enterprise dependencies, as described in those same install procedures.

←  Ops Manager System RequirementsInstall Ops Manager →