Edit a Deployment's Configuration

On this page

Considerations

Prerequisites
Procedure

Ops Manager v6.0 will EOL in January 2025. Upgrade to a higher Ops Manager version as soon as possible.

You can modify a deployment's configuration and topology, including its MongoDB versions, storage engines, and numbers of hosts or shards. You can make modifications at all levels of a deployment's topology from a top-level sharded cluster or replica set to lower levels, such as a replica set within a sharded cluster, or an individual process within a replica set. You can also modify standalone processes.

Considerations

Apply Changes to Cluster or Member

If you make configuration changes to an individual MongoDB process within a cluster, any future changes to the cluster no longer apply to the child process.

Example

If you turn off journaling for a replica set member and then later change the journal commit interval for the replica set, the change does not apply to the member.

MongoDB Version

To choose which versions of MongoDB are available to Ops Manager, see Add a Custom MongoDB Build.

Check the following documents for any considerations or compatibility issues before changing a deployment's MongoDB version:
- The MongoDB Release Notes
  Warning
  Upgrades from MongoDB 5.0 to 6.0
  When you upgrade a sharded cluster from MongoDB 5.0 to 6.0, you must use the procedure on the Upgrade a Sharded Cluster to 6.0 page of the MongoDB Manual to refresh the cached routing table for each mongos.
- The documentation for your driver.
- MongoDB Compatibility Matrix
Plan the version change during a predefined maintenance window.
Change the MongoDB version on a staging environment before changing a production environment. Your staging environment should mirror your production environment. This can help avoid compatibility issues that may result in downtime for your production deployment.
Follow the MongoDB release notes when performing manual upgrades of replica sets and sharded clusters.

Note

Downgrading Limitations

You cannot downgrade a MongoDB deployment:

From version 5.0 to any version before 4.4.0
From version 4.4 to any version before 4.2.6
From version 4.2 to any version 4.0.12 (for Windows) or 4.0.7 (for Linux)
From version 4.0 to any version before 3.6.23

Backup Considerations for MongoDB Versions

To learn more about backup considerations, see Backup Considerations.

Storage Engine

Important

MongoDB removed support for the MMAPv1 storage engine in MongoDB 4.2. If you edit your deployment's configuration to change your storage engine to WiredTiger Storage Engine, Ops Manager restarts the MongoDB processes.

If you run or upgrade to MongoDB 3.0 or later and modify the MongoDB storage engine, Ops Manager shuts down and restarts the MongoDB process. For a multi-member replica set, Ops Manager performs a rolling initial sync of each member.

Ops Manager creates backup directories during the migration from one storage engine to the other if the host has adequate disk space. If disk space is insufficient, no backups are taken. Ops Manager does not delete the backup directories once the migration is complete. You can keep or delete the previous backup directories. The backup directories are located in the mongod's data directory.

Example

If the data directory was /data/process, the backup would be /data/process.bak.UNIQUENAME. The UNIQUENAME is a random string that Ops Manager generates.

Before you can change the storage engine for a standalone instance or replica set, you must give the Automation write access to the MongoDB data directory's parent directory. The agent creates a temporary backup of the data in the parent directory when updating the storage engine. Storage engine changes on standalone instances also require adequate disk space to perform a full /mongodump and /mongorestore. This disk space is then restored to the instance after the storage engine configuration change. Ops Manager does not delete the backup directories.

You cannot change the storage engine on a config server. For more information on storage engines and the available options, see Storage in the MongoDB manual.

Fixed Properties

You cannot modify the following settings after a deployment has been created:

database path
The hostname, bind_ip or port to which a MongoDB process is assigned

You can modify the following deployment settings:

log path at the process level
advanced options

Deployment Topology

You can make modifications at all levels of a deployment's topology, including child processes.

To modify the topology or processes, use this tutorial or one of the more specific tutorials:

Project-Level Modifications

Some modifications that affect a deployment occur at the project level. The following changes affect every MongoDB process in the project. For these changes, use the specified tutorials:

To enable TLS for the deployment, see Enable TLS for a Deployment.
To enable authentication for the deployment, see Enable Authentication for an Ops Manager Project.
To add or modify MongoDB users and roles for the deployment, see Manage MongoDB Users.

Multiple Modifications

You can combine multiple modifications into one deployment.

Example

You could make all the following modifications before clicking the Review Changes button:

Add the latest stable version of MongoDB to the Add a Custom Build.
Enable TLS for the deployment's MongoDB processes.
Add a new sharded cluster running the latest stable version of MongoDB from above.

When you click Review Changes, the review displays all the changes on one screen for you to confirm before deploying.

Force Reconfigure

For Replica Sets and Sharded Clusters Only

The MongoDB Agent can force a replica set to accept a new configuration when you set the Force Reconfigure Replication Setting to Yes. Only force a reconfiguration to recover a replica set from a state in which a minority of its members are available.

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.

Tip

Removing a Shard

For Sharded Clusters Only

When you remove a shard, any unsharded databases in that shard are moved to a remaining shard using the movePrimary command.

All sharded collections remain online and available during the shard removal process. However, read and write operations sent to unsharded collections during the movePrimary operation can result in unexpected behavior, including failure of the migration or loss of data.

We recommend moving the primary shard for any databases containing unsharded collections before removing the shard.

To learn more about removing shards, see Remove Shards from an Existing Sharded Cluster.

Removing Multiple Replica Set Members

You can remove or migrate multiple replica set members at once, but a majority of the voting members must remain. If you need to remove more voting members, remove them one at a time.

Example

Example 1

You have a four-node replica set. All nodes are voting members. You can remove only one node, which preserves the majority of three out of four voting nodes. You can remove another node from the remaining three-node replica set afterward. This preserves the majority of the remaining voting nodes.

Example

Example 2

You have a four-node replica set. Three nodes are voting members and one node is a non-voting member. You can remove one voting member and one non-voting member at the same time. This preserves the majority of two out of three voting nodes.

To learn more about voting, see Replica Set High Availability and Replica Set Elections.

Warning

Upgrades from MongoDB 5.0 to 6.0

When you upgrade a sharded cluster from MongoDB 5.0 to 6.0, you must use the procedure on the Upgrade a Sharded Cluster to 6.0 page of the MongoDB Manual to refresh the cached routing table for each mongos.

All Changes are Clusterwide

Changes cannot be made to individual members of a replica set or sharded cluster, only to the whole set or cluster.

Kubernetes Operator Overrides Some Ops Manager Settings

Some settings that you configure using Kubernetes Operator cannot be overridden in the Ops Manager Application. If you change one of these settings, the Kubernetes Operator reverts the settings each time you apply the resource specification. Settings that the Kubernetes Operator does not manage are accepted.

The following list of settings are exclusive to Kubernetes. This list may change at a later date.

These settings can be found on the Automation Configuration page.

processes.args2_6.net.port
processes.args2_6.replication.replSetName
processes.args2_6.storage.dbPath
processes.args2_6.systemLog.path
processes.authSchemaVersion
processes.cluster (mongos processes)
processes.featureCompatibilityVersion
processes.hostname
processes.name
processes.version
replicaSets._id
replicaSets.members._id
replicaSets.members.host
replicaSets.members
replicaSets.version
sharding.clusterRole (config server)
sharding.configServerReplica
sharding.name
sharding.shards._id
sharding.shards.rs

Example

Kubernetes Operator creates a replica set of 3 members.
You changed storage.wiredTiger.engineConfig.cacheSizeGB to 40.
You then scale the replica set to 5 members.
The storage.wiredTiger.engineConfig.cacheSizeGB on the new members should be 40.

Changes not available in Kubernetes

If a setting is not available for a MongoDB Kubernetes resource, then the change must be made in the Ops Manager Application.

Prerequisites

Your deployment must be running a version of the Automation that is compatible with Ops Manager. If your deployment is not running a compatible version of the agent, Ops Manager displays a banner prompting you to update your agents.

You must have enough disk space in the parent directory to perform backups before making storage engine changes on standalone processes. We recommend using replica sets instead of standalone processes, which apply changes in a rolling fashion.

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

Procedure

Select the type of deployment you want to edit:

Navigate to the Deployment page for your project.

If it is not already displayed, select the organization that contains your desired project from the 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.

On the line listing the deployment item, click Modify.

Modify the Standalone Settings.

The Standalone Settings section contains the following configuration settings:

Setting	Description
Hostname	Hostname to which Ops Manager deploys the `mongod`. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. You can only deploy to hosts under Ops Manager automation. For complete documentation on adding servers to Ops Manager automation, see Provision Servers for Automation.
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.
Version	Select the MongoDB server version of the `mongod` process. Ops Manager lists only the MongoDB versions that are available for your deployment. To disable this filtering, see `automation.versions.download.baseUrl.allowOnlyAvailableBuilds`.
Auth Schema Version	Select the schema for storing the user for storing the user data for your deployment. If you are upgrading from a MongoDB version older than 3.0, MongoDB 3.0+ uses a different schema for user data than previous versions. For compatibility information, see the Security Changes in the MongoDB 3.0 release notes.
Feature Compatibility Version	Select the Feature Compatibility Version of the deployment. Ops Manager displays this field if your deployment runs MongoDB version 3.4 or later.
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. For example, specifying `/var/log/mongodb/mongo.log` directs the `mongod` to store its logfile in `/var/log/mongodb/` as `mongo.log`. The `mongod` must have its own unique log file. If deploying multiple `mongod` processes to the same host, ensure each `mongod` has its own distinct logfile.

Modify Advanced Configuration Options.

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.
Click Select a Startup Option and select the configuration option.
Ops 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 the process.

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

Click Save.

Ops Manager redirects you to the Deployment page, where you must review your changes before deploying the updated configuration.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Otherwise, click Cancel and you can make additional changes.

Navigate to the Deployment page for your project.

If it is not already displayed, select the organization that contains your desired project from the 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.

On the line listing the deployment item, click Modify.

Modify Cluster-Wide Settings.

The Replica Set Configuration section contains the following cluster-wide configuration settings.

Setting	Description
Auth Schema Version	Select the schema for storing the user for storing the user data for your deployment. If you are upgrading from a MongoDB version older than 3.0, MongoDB 3.0+ uses a different schema for user data than previous versions. For compatibility information, see the Security Changes in the MongoDB 3.0 release notes.
Feature Compatibility Version	Select the Feature Compatibility Version of the deployment. Ops Manager displays this field if your deployment runs MongoDB version 3.4 or later.
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. Ops Manager initially groups each process under the replica set name. Click the to the left of the replica set name to display all `mongod` processes in the replica set. Ops 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. Ops Manager lists only the MongoDB versions that are available for your deployment. To disable this filtering, see `automation.versions.download.baseUrl.allowOnlyAvailableBuilds`.
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. For example, specifying `/var/log/mongodb/mongo.log` directs the `mongod` to store its logfile in `/var/log/mongodb/` as `mongo.log`. The `mongod` must 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 configurable 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 `secondaryDelaySecs` 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. 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 `secondaryDelaySecs` `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.

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. To learn more, see Reconfigure a Replica Set with Unavailable Members in the MongoDB Server Manual.

Modify Advanced Configuration Options.

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 Advanced Options.
Click Select a Startup Option and select the configuration option.
Ops 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.

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

Click Save.

Ops Manager redirects you to the deployment page, where you must review your changes before deploying the updated configuration.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Otherwise, click Cancel and you can make additional changes.

Ops Manager displays the following message if you attempt to force reconfigure a replica set.

Diagram that |mms| displays when you attempt to force reconfigure a replica set.

click to enlarge

Before you click Confirm & Deploy, make sure that you understand the risks of force reconfiguring a replica set.

Tip

Navigate to the Deployment page for your project.

If it is not already displayed, select the organization that contains your desired project from the 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.

On the line listing the deployment item, click Modify.

Configure Cluster-Wide Settings.

The Cluster Configuration section contains the following cluster-wide configuration settings.

Setting	Description
Shard Name Prefix	Specify the prefix of each shard in the cluster. Ops Manager names each shard in the cluster using the `<prefix_n>` format, where `n` is a 0-indexed, monotonically increasing integer.
Auth Schema Version	Select the schema for storing the user for storing the user data for your deployment. If you are upgrading from a MongoDB version older than 3.0, MongoDB 3.0+ uses a different schema for user data than previous versions. For compatibility information, see the Security Changes in the MongoDB 3.0 release notes.
Feature Compatibility Version	Select the Feature Compatibility Version of the deployment. Ops Manager displays this field if your deployment runs MongoDB version 3.4 or later.
Process Name	Hostname and port of a `mongod` or `mongos` associated to the sharded cluster. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. Ops Manager groups `mongod` processes under their parent replica set name, and `mongos` processes under mongoses. Ops Manager then groups all the cluster components under the cluster name. Click the to the left of a grouping to list its sub-groups or processes. Modifying any of the available settings for a grouping changes the corresponding value in its sub-groups and processes. For clusters running MongoDB 3.0 or earlier, Ops Manager groups the config server `mongod` processes under configServers.
Version	Select the MongoDB server version of the `mongod` or `mongos` process. Ops Manager lists only the MongoDB versions that are available for your deployment. To disable this filtering, see `automation.versions.download.baseUrl.allowOnlyAvailableBuilds`.
Log File	Specify the full path to the `mongod` or `mongos` log file, including the log file name and extension. This setting corresponds to the `systemLog.path` configuration file option. The `mongod` or `mongos` must have permission to read and write to the specified file. For example, specifying `/var/log/mongodb/mongo.log` directs the `mongod` or `mongos` to store its logfile in `/var/log/mongodb/` as `mongo.log`. The `mongod` or `mongos` must have its own unique log file. If deploying multiple `mongod` or `mongos` processes to the same host, ensure each `mongod` or `mongos` has its own distinct logfile.

Configure Each Shard in Your Cluster.

From the Member Configuration section, click Shard Settings to open the shard configuration options. Ops Manager lists each shard in the cluster and the mongod processes associated to that shard. Each shard process has the following options. You cannot modify options that are greyed out:

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 `secondaryDelaySecs` 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. 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 `secondaryDelaySecs` `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.

To add additional shards to the cluster:

Click Add a Shard.
Under the Cluster Configuration section, set the following parameters for each mongod in the shard:
- Version
- Data Directory
- Log File

Configure Each Configuration Server in Your Cluster.

Ops Manager displays a different heading for your configuration server settings depending on the MongoDB version you selected for your configuration servers.

MongoDB 3.2 or Later:

From the Member Configuration section, click Config Server Replica Set Settings to open the CSRS configuration options. Each config server 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 `secondaryDelaySecs` 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. 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 `secondaryDelaySecs` `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 Cluster Configuration section. You must configure the Version, Data Directory, and Log File of the new process.

MongoDB 3.0 or Earlier

From the Member Configuration section, click Config Server Settings to open the configuration server options. Each configuration server has the following options:

Setting	Description
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. 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.

Configure Each `mongos` in Your Cluster.

From the Member Configuration section, click Mongos Settings to open the mongos configuration options. Each mongos process has the following options. You cannot modify options that are greyed out:

Setting	Description
Hostname	Select from the menu the host to which Ops Manager Automation deploys the `mongos`. The menu only lists hosts under Ops Manager Automation. For complete documentation on adding servers to Ops 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 `mongos` process. This setting corresponds to the `net.port` configuration file option. Defaults to `27017`. The `mongos` must have exclusive access to the specified port. If deploying multiple `mongos` processes to a single host, you must select a unique unused port for each process.
Add a Mongos	Click to add an additional `mongos` process.

Configure Each Replica Set in your Cluster.

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

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. To learn more, see Reconfigure a Replica Set with Unavailable Members in the MongoDB Server Manual.

Modify Advanced Configuration Options.

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 Advanced Options.
Click Select a Startup Option and select the configuration option.
Ops 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.

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

Click Save.

Ops Manager redirects you to the deployment page, where you must review your changes before deploying the updated configuration.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Otherwise, click Cancel and you can make additional changes.

Edit the Kubernetes resource specification file.
Modify or add any settings you need added or changed.
Save your specification file.
Invoke the following Kubernetes command to update your resource.
```
kubectl apply -f <standalone-conf>.yaml
```

Back

Prepare for Cluster Maintenance

Manage BI Connector in Ops Manager

Considerations

Apply Changes to Cluster or Member

Example

MongoDB Version

Warning

Upgrades from MongoDB 5.0 to 6.0

Note

Downgrading Limitations

Backup Considerations for MongoDB Versions

Storage Engine

Important

Example

Fixed Properties

Deployment Topology

Project-Level Modifications

Multiple Modifications

Example

Force Reconfigure

Tip

See also:

Removing a Shard

Removing Multiple Replica Set Members

Example

Example 1

Example

Example 2

Warning

Upgrades from MongoDB 5.0 to 6.0

All Changes are Clusterwide

Kubernetes Operator Overrides Some Ops Manager Settings

Example

Changes not available in Kubernetes

Prerequisites

Procedure

Navigate to the Deployment page for your project.

On the line listing the deployment item, click Modify.

Modify the Standalone Settings.

Modify Advanced Configuration Options.

Click Save.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Navigate to the Deployment page for your project.

On the line listing the deployment item, click Modify.

Modify Cluster-Wide Settings.

Configure Each Replica Set Member.

Configure your Replication Settings.

Modify Advanced Configuration Options.

Click Save.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Tip

See also:

Navigate to the Deployment page for your project.

On the line listing the deployment item, click Modify.

Configure Cluster-Wide Settings.

Configure Each Shard in Your Cluster.

Configure Each Configuration Server in Your Cluster.

Configure Each mongos in Your Cluster.

Configure Each Replica Set in your Cluster.

Modify Advanced Configuration Options.

Click Save.

Click Review & Deploy to review your changes.

Click Confirm & Deploy to deploy your changes.

Configure Each `mongos` in Your Cluster.