- Install Ops Manager >
- Deploy Backing MongoDB Replica Sets
Deploy Backing MongoDB Replica Sets¶
On this page
Overview¶
Ops Manager uses two dedicated replica sets to store operational data: one replica set to store the Ops Manager Application Database and another to store the Backup Database. If you use multiple Backup Databases, set up separate replica sets for each database.
Note
You cannot use Ops Manager to manage Ops Manager’s backing instances. You must deploy and manage the backing instances manually.
The backing MongoDB replica sets are dedicated to operational data and must store no other data.
Replica Sets Requirements¶
The replica set that hosts the Ops Manager Application Database and each replica set that hosts a Backup Database must:
- Store data in support of Ops Manager operations only and store no other data.
- Run on a server that meets the server prerequisites below.
- Run MongoDB 3.0.6 or later if running MongoDB 3.0 or run MongoDB 2.6.6 or later if running MongoDB 2.6. Do not use a MongoDB version earlier than 2.6.6.
- Use the storage engine appropriate to your workload. In most cases, this is MMAPv1. See storage engine considerations below.
- 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. - Must not run the MongoDB
notablescan
option.
Server Prerequisites¶
The servers that run the replica sets must meet the following requirements.
The hardware requirements described in Ops Manager Application Database Hardware or Ops Manager Backup Database Hardware, 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 important information on ulimits, NUMA, Transparent Huge Pages (THP), 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: if the
/etc/security/limits.d
directory contains the90-nproc.conf
file, remove the file. The file overrideslimits.conf
, decreasingulimit
settings. Issue the following command to remove the file:
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.
Procedures¶
Install MongoDB on Each Server¶
Warning
Failure to configure servers according to the MongoDB Production Notes can lead to production failure.
Use servers that meet the above prerequisites.
The following procedure assumes that you
are installing MongoDB on a server running Red Hat Enterprise Linux (RHEL).
If you are installing MongoDB on another operating system,
or if you prefer to use cURL
rather than yum
,
see the Install MongoDB section
in the MongoDB manual.
To install MongoDB on a server running RHEL:
Create a repository file on each server by issuing the following command:¶
Install MongoDB on each server by issuing the following command:¶
Deploy a Backing Replica Set¶
This procedure deploys a three-member replica set dedicated to store either the Ops Manager Application Database or Backup Database. Deploy the replica set to three servers that meet the requirements for the database.
Repeat this procedure for each backing replica set that your installation requires. For additional information on deploying replica sets, see Deploy a Replica Set in the MongoDB manual.
Create a data directory on each server.¶
Create a data directory on each server and set mongod
as the
directory’s owner. For example:
Start each MongoDB process.¶
For each replica set member, start the mongod process and
specify mongod
as the user. Start each process on its own dedicated
port and point to the data directory you created in the
previous step. Specify the same replica set for all three members.
The following command starts a MongoDB process as part of a replica
set named operations
and specifies the /data
directory.
Connect to the MongoDB process on the server that will initially host the database’s primary.¶
For example, the following command connects on port 27017
to a
MongoDB process running on mongodb1.example.net
:
When you connect, the MongoDB shell displays its version as well as the database to which you are connected.
Initiate the replica set.¶
To initiate the replica set, issue the following command:
MongoDB returns 1
upon successful completion, and creates a
replica set with the current mongod as the initial member.
The server on which you initiate the replica set becomes the initial primary. The mongo shell displays the replica set member’s state in the prompt.
MongoDB supports automatic failover, so this mongod may not always be the primary.
Verify the replica set configuration.¶
To verify that the configuration includes the three members, issue rs.conf():
The method returns output similiar to the following.
Optionally, run rs.status() </reference/method/rs.status to verify the status of the replica set and see the state of each replica set member.
For more information on deploying replica sets, see Deploy a Replica Set in the MongoDB manual.