Deploy a Replica Set

A replica set is a group of MongoDB deployments that maintain the same data set. Replica sets provide redundancy and high availability and are the basis for all production deployments.

To learn more about replica sets, see the Replication Introduction in the MongoDB manual.

Use this procedure to deploy a new replica set managed by Ops Manager. After deployment, use Ops Manager to manage the replica set, including such operations as adding, removing, and reconfiguring members.


You must provision servers onto which to deploy, and Ops Manager must have access to the servers.


If you will run MongoDB Enterprise and provision your own Linux servers, then you must manually install a set of dependencies to each server before installing MongoDB. The MongoDB manual provides the appropriate command to install the dependencies. See the link for the server’s operating system:

Added in Ops Manager 4.0

You can use Kubernetes to deploy MongoDB instances with Ops Manager version 4.0 or later.

To deploy a standalone using a Kubernetes object, you need to meet the prerequisites for, and complete the procedures on, the Install Kubernetes Operator page.


Unique Names for Replica Set

Use a unique name for the replica set.


Replica set, sharded cluster, and shard names within the same project must be unique. Failure to have unique names for the deployments will result in broken backup snapshots.



Click Deployment.


Open the Cluster Creation View.

Click the Add New arrow in the top-right of the Deployment page. Select New Replica Set from the drop-down menu to open the Create New Replica Set view.


Configure Cluster-Wide Settings.

The Replica Set Configuration section contains the following cluster-wide configuration settings. Settings marked with an * asterisk in the Ops Manager UI are required.

Setting Description
Replica Set Id Enter the name of your replica set deployment. You cannot change this once set. This setting corresponds to the _id replica configuration option.
Replica Set Settings Displays an table of each process associated with the replica set. You can configure the MongoDB server version, data directory, and log path of each process.
Process Name

Hostname and port of a mongod process. Ops Manager initially groups each process under the replica set name. Click the caret right icon to the left of the replica set name to display all bin.mongod processes in the replica set.

Ops Manager applies any settings configured for the replica set to all of its associated processes.


Select the MongoDB server version of the mongod process.

If the dropdown menu does not include the MongoDB version you want for your deployment, you must enable it in the Version Manager.

Data Directory

Specify the directory where the mongod process stores data files. This setting corresponds to the storage.dbPath mongod configuration file option. The Ops Manager Automation Agent must have file system permission to read, write, and execute all files and folders in the specified directory.

Each mongod process must have its own database directory. If deploying multiple mongod processes on the same host, ensure each process has its own distinct directory.

Log File

Specify the full path to the mongod log file, including the log file name and extension. This setting corresponds to the systemLog.path configuration file option. The mongod must have permission to read and write to the specified file.


Specifying /var/log/mongodb/mongo.log directs the mongod to store its logfile to /var/log/mongodb/ as mongo.log.

The mongod have its own unique log file. If deploying multiple mongod processes to the same host, ensure each mongod has its own distinct logfile.


Configure each Replica Set Member.

Ops Manager lists each replica set member under the MongoD Settings heading of the Member Configuration section. Each replica set member has the following options:

Setting Description

Select one of the following replica set member roles from the menu:

  • Default

    A data-bearing member of the replica set that can become the primary and vote in elections.

  • Arbiter

    A non-data bearing member of the replica set that can vote in elections. Corresponds to the arbiterOnly replica configuration option.

  • Hidden

    A data-bearing member of the replica set that can vote in elections. Corresponds to the hidden replica configuration option.

  • Delayed Hidden

    A data-bearing member of the replica set that can vote in elections. Corresponds to the slaveDelay and hidden replica configuration options.

Hostname Select from the menu the host to which Ops Manager Automation deploys the replica set member. The menu only lists hosts under Ops Manager Automation. For complete documentation on adding servers to Ops Manager Automation, see Provision Servers for Automation.

Specify the IANA port number for the mongod process. This setting corresponds to the net.port configuration file option. Defaults to 27017.

The mongod must have exclusive access to the specified port. If deploying multiple mongod processes to a single host, you must select a unique unused port for each process.

Votes Specify the number of votes that the replica set member has during elections. This setting corresponds to the votes mongod replica set configuration option.
Priority Specify the priority of the member during elections. Replica set members with a priority of 0 cannot become the primary and cannot trigger elections. This setting corresponds to the priority mongod replica set configuration option.
Delay Specify the number of seconds “behind” the primary member this member should “lag”. This setting corresponds to the slaveDelay mongod replica set configuration option.
Build Indexes Specify true to direct the mongod to build indexes. This setting corresponds to the buildIndexes mongod replica set configuration option.

Specify the tag or tags associated to the replica set. This setting corresponds to the tags mongod replica set configuration option.

For complete documentation on replica set tags, see Replica Set Tags

Add a Mongod

Adds an additional mongod process as a replica set member.

Adding a new mongod process also updates the list of processes in the Replica Set Configuration section. You must configure the Version, Data Directory, and Log File of the new process.


Configure your Replication Settings.

The Replication Settings section contains the following configuration options for the replica set:

Setting Description
Protocol Version

Select the replication protocol version used by the replica set. This setting corresponds to the protocolVersion replica set configuration option.

For more information, see Replica Set Protocol Versions.

Chaining Allowed Specify true to allow secondary members to replicate from other secondary members. This setting corresponds to the chainingAllowed replica set configuration option.
Write Concern Majority Journal Default Determines the behavior of {w:"majority"} write concern if the write concern does not explicitly specify the journal option j. This setting corresponds to the writeConcernMajorityJournalDefault replica set configuration option.
Heartbeat Timeout (secs) Specify the number of seconds that the replica set members wait for a successful heartbeat from each other. This setting corresponds to the heartbeatTimeoutSecs replica set configuration option.
Election Timeout (ms) Specify the time limit in milliseconds for detecting when a replica set’s primary is unreachable. This setting corresponds to the electionTimeoutMillis replica set configuration option.
CatchUp Timeout (ms) Specify the time limit in milliseconds for a newly elected primary to sync, or catch up, with the other replica set members that may have more recent writes. This setting corresponds to the catchUpTimeoutMillis replica set configuration option.
CatchUp Takeover Delay (ms) Specify the time in milliseconds a node waits to initiate a catchup takeover after determining it is ahead of the current primary. This setting corresponds to the catchUpTakeoverDelayMillis replica set configuration option.
Last Error Defaults

Specify the default write concern for the replica set. The replica set uses this write concern only when write operations or getLastError specify no other write concern.

If this option is not set, the default write concern for the replica set only requires confirmation from the primary.

Specify this option in the form of a document, i.e., {"w":2}.


Configure your Ops Manager managed indexes.

The Index Configuration section allows you to create, change, or remove Ops Manager managed indexes on your MongoDB deployment. For complete documentation on Ops Manager managed indexes, see Manage Indexes.

Setting Description
Add Adds an index for Ops Manager to manage. Select an index type to open the index creation walkthrough.
Unmanage Removes the index from Ops Manager management. Only visible if you have at least one Ops Manager managed index. Removing an index from Ops Manager management does not delete the index.

Set any advanced configuration options for your MongoDB replica set.

The Advanced Options section allows you to set MongoDB runtime options for each MongoDB process in your deployment.

To add an option:

  1. Click Add Option.
  2. From the Select a Process Type menu, click the process for which you want to add an option.
  3. Click Select a Startup Option and select the configuration option.
  4. Ops Manager displays a context-sensitive input for configuring an acceptable value for the selected option.
  5. Click Add to add the selected option and its corresponding value to every process of the selected process type in the cluster.

Ops Manager lists each process in the cluster grouped logically. Click the grey arrow to the left of the logical grouping to display its sub-groupings and processes. You can modify the advanced options for each process individually as necessary.

For descriptions of the available Advanced Options, see Advanced Options for MongoDB Deployments.


Click Create Replica Set.

Ops Manager automatically deploys the replica set as configured. You can monitor the progress of cluster deployment from the Deployment view.


Copy the following example replica set Kubernetes object.

This is a YAML file that you can modify to meet your desired configuration. The highlighted lines should be changed for your replica set configuration.

kind: MongoDbReplicaSet
  name: <myreplicaset>
  namespace: <metadata.namespace> # Should match metadata.namespace in
                                  # your configmap file.
  members: 3
  version: 3.6.7
  project: <myconfigmap> # Should match in your
                         # configmap file.
  credentials: <mycredentials>
  persistent: true

Change the highlighted settings to match your desired replica set deployment.


Open your preferred text editor and paste the object specification into a new text file.


Configure the settings highlighted in the above example as follows.

Key Type Description Example string

Label for this Kubernetes replica set object.

See also

metadata.namespace string

Scope of object names. Kubernetes namespace where this MongoDB Kubernetes resource and other objects are created.

Using two different namespaces allows you to delete your standalone or all of the resources in the namespace without affecting your Kubernetes Operator.

See also

spec.project string

Name of the ConfigMap with the Ops Manager connection configuration.

Value must match namespace and name of ConfigMap

This value must match the value you provided for in your Ops Manager project ConfigMap.

If this MongoDB Kubernetes resource is in a different namespace than the project ConfigMap, you should set this value to the namespace and name of the ConfigMap in this format: <metadata.namespace>/<>

<myconfigmap> or <namespace>/<myconfigmap>
spec.credentials string

Name of the Kubernetes secret you created as Ops Manager API authentication credentials for the Kubernetes Operator to communicate with Ops Manager.

Value must use namespace and name of Secret

This value must match the value you provided for namespace and name for your Ops Manager Kubernetes Secret.

If this object is in a different namespace than the Secret, you should set this value to the namespace and name of the Secret in this format: <namespace>/<name>

<mycredentials> or <namespace>/<mycredentials>
spec.version string

Version of MongoDB that this replica set should run.

The format should be X.Y.Z for the Community edition and X.Y.Z-ent for the Enterprise edition.

To learn more about MongoDB versioning, see MongoDB Version Numbers in the MongoDB Manual.

spec.members integer Number of members of the replica set. 3
spec.persistent string


Flag indicating if this MongoDB Kubernetes resource should use Persistent Volumes for storage. Persistent volumes are not deleted when the MongoDB Kubernetes resource is stopped or restarted.

If this value is true, then spec.podSpec.persistence.single is set to its default value of 16G.

To change your Persistent Volume Claims configuration, configure the following collections to meet your deployment requirements:


Your containers must have permissions to write to your Persistent Volume. The Kubernetes Operator sets fsGroup = 2000 in securityContext This makes Kubernetes try to fix write permissions for the Persistent Volume. If redeploying the deployment item does not fix issues with your Persistent Volumes, contact MongoDB support.


If you do not use Persistent Volumes, the Disk Usage and Disk IOPS charts cannot be displayed in either the Processes tab on the Deployment page or in the Metrics page when reviewing the data for this deployment.


Save this file with a .yaml file extension.


Start your replica set deployment.

Invoke the following Kubernetes command to create your replica set:

kubectl apply -f <replica set-conf>.yaml

To troubleshoot your replica set, see: