Deploy a Replica Set¶

On this page

Prerequisites
Considerations
Procedure

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 Cloud Manager. After deployment, use Cloud Manager to manage the replica set, including such operations as adding, removing, and reconfiguring members.

New in Cloud Manager

You can use Kubernetes to deploy MongoDB instances with Cloud Manager.

To learn how to deploy a replica set using a Kubernetes object, see Deploy a Replica Set in the MongoDB Enterprise Kubernetes Operator documentation.

Prerequisites¶

To deploy MongoDB clusters, you must provision hosts to serve those clusters. Cloud Manager requires access to these hosts.

Important

If you run MongoDB Enterprise and provision your own Linux hosts, 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.

To learn more about the specifics for an operating system, see the following:

Considerations¶

Unique Names for Replica Set¶

Use a unique name for the replica set.

Important

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.

Procedure¶

1

Navigate to the Deployment page for your project.¶

If it is not already displayed, select the organization that contains your desired project from the office icon Organizations menu in the navigation bar.
If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
If it is not already displayed, click Deployment in the sidebar.

2

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.

3

Configure Cluster-Wide Settings.¶

The Replica Set Configuration section contains the following cluster-wide configuration settings. Settings marked with an * asterisk in the Cloud 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. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. Cloud 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 `mongod` processes in the replica set. Cloud Manager applies any settings configured for the replica set to all of its associated processes.
Version	Select the MongoDB server version of the `mongod` process.
Data Directory	Specify the directory where the `mongod` process stores data files. This setting corresponds to the `storage.dbPath` `mongod` configuration file option. The Cloud Manager Automation 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. Example 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.

4

Configure each Replica Set Member.¶

Cloud 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
Member	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 Cloud Manager Automation deploys the replica set member. The menu only lists hosts under Cloud Manager Automation. For complete documentation on adding servers to Cloud Manager Automation, see Provision Servers for Automation. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address.
Port	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.
Tags	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.

5

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}`.
Force Reconfigure	Specify that you want to force a reconfiguration of the replica set. When set to `Yes`, the MongoDB Agent forces the replica set to accept a new configuration even if a majority of its members are unavailable. Warning Forcing a replica set reconfiguration might lead to a rollback of majority-committed writes. Proceed with caution. Contact MongoDB Support if you have questions about the potential impacts of this operation. See also Reconfigure a Replica Set with Unavailable Members in the MongoDB Server Manual.

6

Set the default read and write concerns for your MongoDB replica set.¶

In the Default Read Concerns/Write Concerns card, you configure the default level of acknowledgement requested from MongoDB for read and write operations for this cluster. Setting the default read and write concern can help with MongoDB 5.0 deployments using arbiters.

From the Default Read Concerns section, you can set consistency and isolation properties for the data read from the cluster.

Select the default read concern from the Level dropdown menu. You can choose from the following values:

local, the MongoDB 5.0 default value,
available, the MongoDB 4.4 default value, or
majority.

From the Default Write Concerns section, you configure the default level of acknowledgment requested from MongoDB for write operations from the cluster. You can set three parameters:

Parameter Value

w Option

Desired number of mongod instances that must acknowledge a write operation. You can enter one of the following values:

majority, the MongoDB 5.0 default value, or
Any positive integer. MongoDB 4.4 defaults to 1.

j Option Flag that indicates whether the write acknowledgement must be written to the on-disk journal.

w Timeout Desired time limit for the write concern expressed in milliseconds. Set this value when you set w to a value greater than 1 including majority.

7

Set any advanced configuration options for your MongoDB replica set.¶

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

To add an option:

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

Cloud 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 Configuration Options, see Advanced Options for MongoDB Deployments.

8

Click Create Replica Set.¶

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

← Add Existing MongoDB Processes to Cloud Manager Deploy a Sharded Cluster →

Cloud Manager will no longer support Automation for MongoDB 3.4 clusters after February 10, 2022. Please upgrade your MongoDB deployment or migrate to Atlas.