Install Ops Manager >
Install the Ops Manager Application Database and Backup Database

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	Application Database	Backup Database
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	Yes
Can Ops Manager manage the 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	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:

Finish installing the backing databases.
Install Ops Manager Application.
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.

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 Backing Database for S3 Block and Oplog Metadata¶

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

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 Each Version of Ops Manager¶
Ops Manager Release	MongoDB 4.2	MongoDB 4.4	MongoDB 5.0
Ops Manager 5.0	check circle icon	check circle icon	check circle icon

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

Example

Ops Manager 5.0 supports the entire MongoDB release series from 4.0.0 to 4.0.20.

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.

Grant Minimal Roles to the Ops Manager User that Accesses the Backing Databases¶

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.

Hostnames¶

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.

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.

copy

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:

For MongoDB Community edition, see Configure SELinux
For MongoDB Enterprise edition, see Configure SELinux

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.