- Install Ops Manager >
- Install the Ops Manager Application Database and Backup Database
Install the Ops Manager Application Database and Backup Database¶
On this page
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 totrue
, 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.
- 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.mongoUri
setting. You will also specify theauthentication 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:
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.
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.
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.