- 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 Blockstore Database. If you use multiple application or blockstore databases, set up separate replica sets for each database.
The backing MongoDB replica sets are dedicated to operational data and must store no other data.
Replica Sets Requirements¶
Each replica set that hosts the Ops Manager Application Database or a Backup Database:
- Stores data in support of Ops Manager operations only and stores no other data.
- Must run on a server that meets the server prerequisites below.
- Must run MongoDB 2.4.9 or later.
- Must use the MMAPv1 storage engine.
- Must have the MongoDB
security.javascriptEnabled
set 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 Blockstore 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:
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 Linux operating system,
or you prefer to use cURL
rather than yum
,
refer to the installation guides
in the MongoDB manual.
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 Blockstore 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.
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.