- Install Ops Manager >
- Install the Ops Manager Application Database and Backup Database
Install the Ops Manager Application Database and Backup Database¶
On this page
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.
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.
- Set the MongoDB
true, which is the default. The Ops Manager Application uses the
$wherequery and requires this setting be enabled on the Ops Manager Application Database.
- Do not run the MongoDB
- Set the MongoDB
- 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.mongoUrisetting. You will also specify the
authentication mechanismif the database uses a mechanism other than default MongoDB authentication.
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
/etc/security/limits.d/99-mongodb-nproc.confdoes 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 Application and Backup 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, MMAPv1 performs best given 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.
To deploy MongoDB replica sets to host the Ops Manager Application and Backup Databases: