Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Install the Ops Manager Application Database and Backup Database

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:

Database Application Database Backup Database
What does the database store? Ops Manager operational data Oplog data, temporary sync data, and, depending on your configuration, your snapshots
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 Yes
Can Ops Manager manage the database? No 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.

Considerations

Replica Set Topology

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.

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.

Application Database Monitoring

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.

See also

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

Prerequisites

Replica Set Configuration

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

Use Dedicated Databases
The replica sets must store data to support Ops Manager metadata only. They must store no other data.
Use a Compatible MongoDB Version

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

Supported Versions of MongoDB for Backing Databases on Each Version of Ops Manager
Ops Manager Release Series MongoDB 3.4 MongoDB 3.6 MongoDB 4.0 MongoDB 4.2 MongoDB 4.4
Ops Manager 4.2   check icon check circle icon check circle icon  
Ops Manager 4.4     check icon check circle icon check circle icon

The preceding table uses this convention:

check circle icon Version supported
check icon Version deprecated

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

Example

Ops Manager 4.0 and 4.2 support the entire MongoDB release series from 3.6.0 to 3.6.19.

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 the WiredTiger Storage Engine for the Application Database
Use WiredTiger for the Ops Manager application database.
Use the WiredTiger Storage Engine for the Backup Database
For backup database configuration options, see Backup Preparations.
Use Queries that Do Not Require Indexes
Do not run the backing databases with the MongoDB --notablescan parameter set. When set, this parameter specifies that all queries must use indexes.

Replica Set Security

Secure the Connection to the Backing Databases
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.
Configure an Authentication Mechanism for the Backing Databases
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.
Configure the Ops Manager User that Accesses the Backing Databases with Only Needed Roles
Set these users to have the readWriteAnyDatabase and dbAdminAnyDatabase roles. If a backing database is a sharded cluster, add clusterAdmin, otherwise add clusterMonitor.

Host Configuration

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

Hardware
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.
System Configuration
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.
Networking
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 hosts only

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.

RHEL and CentOS hosts running SELinux in enforcing mode

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:

Deploy Backing Databases

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

1

Provision hosts.

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

Install MongoDB on each host.

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.

Next Steps