Navigation
You were redirected from a different version of the documentation. Click here to go back.

Install the Ops Manager Application Database and Backup Database

Overview

Before you install Ops Manager you must install the Ops Manager Application Database, which holds Ops Manager operational data. If you will use the Ops Manager Backup feature, you must also install the Backup Database, which stores oplog data, temporary sync data, and, depending on your configuration, stores your snapshots.

Both databases run on dedicated MongoDB replica sets. If you use multiple Backup Databases, set up separate replica sets for each database. The replica set for each database is dedicated to that database only and must store no other data.

The application database and the backup database(s) run as separate replica sets to ensure that the Ops Manager Application would keep running should you accidentally fill the Backup Database’s volume. If that occurred and both databases were members of the same replica set, Ops Manager would become inoperable.

Note

You cannot use Ops Manager to deploy the backing database. You must deploy and manage the backing databases manually.

Replica Set Topology

Each replica set usually comprises three data-bearing members to provide high availability. If you cannot allocate space for three data-bearing members, the third member can be an arbiter, but keep in mind that Ops Manager uses w:2 write concern, which reports a write operation as successful after acknowledgement from the primary and one secondary. If you use a replica set with only two data-bearing members, and if you lose one of the data-bearing members, MongoDB blocks write operations.

For the Ops Manager Application Database, you can optionally run one member of the replica set on the same physical server as Ops Manager. For testing only, you may use a standalone MongoDB deployment in place of each replica set.

Replica Sets Requirements

The replica sets that host the Ops Manager Application Database and Backup Database(s) must:

  • Dedicated Databases: The replica sets must store data only in support of Ops Manager operations. They must store no other data.
  • MongoDB Version: The replica sets must run MongoDB 2.6.6 or later. If they run a 3.0+ version of MongoDB, the replica sets must run MongoDB version 3.0.6 or later.
  • Storage Engine: Use the storage engine appropriate to your workload. In most cases, this is MMAPv1. See the storage engine considerations below.
  • Settings:
    • Set the MongoDB security.javascriptEnabled option to true, which is the default. The Ops Manager Application uses the $where query and requires this setting be enabled on the Ops Manager Application Database.
    • Do not run the MongoDB notablescan option.
  • Credentials: The replica sets must include user credentials for accessing the backing database. When you install Ops Manager, you will include the user credentials in the mongo.mongoUri setting. You will also specify the authentication mechanism if the database uses a mechanism other than default MongoDB authentication.

Server Prerequisites

The servers that run the replica sets must meet the following requirements.

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

  • The system requirements in the MongoDB Production Notes. The Production Notes include information on ulimits, NUMA, and other configuration options.

  • The MongoDB ports requirements described in Firewall Configuration. Each server’s firewall rules must allow access to the required ports.

  • RHEL servers only:

    RHEL places a max process limitation of 1024 which overrides ulimit settings. If /etc/security/limits.d/99-mongodb-nproc.conf does not exist, create the file with new soft nproc and hard nproc values to increase the process limit. See /etc/security/limits.d/90-nproc.conf file as an example.

    For more information, see UNIX ulimit Settings in the MongoDB manual.

Choosing a Storage Engine for the Backing Databases

MongoDB provides both the MMAPv1 and WiredTiger storage engines. The Ops Manager Application and Backup Database schemas have been designed to achieve maximum performance on MMAPv1. Therefore, while WiredTiger outperforms MMAPv1 on typical workloads, we recommend MMAPv1 for the unique Ops Manager workload.

The MMAPv1 engine also minimizes storage in the Backup Database’s blockstore, as all the blocks are already compressed and padding is disabled. There is typically no further storage benefit to be gained by taking advantage of WiredTiger compression.

In one case, WiredTiger might be preferable. Backups of insert-only MongoDB workloads that benefit from high levels of block-level de-duplication in the blockstore may see a compression-based storage reduction when running the Backup Database on the WiredTiger storage engine.

The storage engine used by the Backup Database is independent from the storage engine chosen to store a deployment’s snapshots. If the Backup Database uses the MMAPv1 storage engine, it can store backup snapshots for WiredTiger backup jobs in its blockstore.

Procedure

To deploy MongoDB replica sets to host the Ops Manager Application and Backup Databases:

1

Provision servers.

Use servers that meet the above Server Prerequisites.

Warning

Failure to configure servers according to the MongoDB Production Notes can lead to production failure.

2

Install MongoDB on each server.

To install MongoDB, see Install MongoDB 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 the install procedures.

3

Deploy the replica set for each database.

Deploy separate replica sets for the Ops Manager Application Database and for each Backup Database. To deploy replica sets, see Deploy a Replica Set in the MongoDB manual.