Edit a Deployment’s Configuration


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.


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. For 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 will not apply to the member.


MongoDB Version

To choose which versions of MongoDB are available to Ops Manager, see Configure Available MongoDB Versions.

  • Check the following documents for any considerations or compatibility issues before changing a deployment’s MongoDB version:

  • 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.

  • Perform any downgrades in two stages if your MongoDB configuration file includes options incompatible with the earlier MongoDB version:

    1. Remove the configuration settings specific to the newer MongoDB version. Deploy those changes.


      If you are running MongoDB version 3.0 with the engine option set to mmapv1, and want to downgrade to MongoDB 2.6, you must first remove the engine option. MongoDB 2.6 does not support that option.

    2. Update the MongoDB version. Deploy that change.


    • You may not downgrade a MongoDB deployment from version 3.4 to any version before 3.2.8.
    • Ops Manager blocks users attempts to downgrade from featureCompatibilityVersion=3.4 to featureCompatiblityVersion=3.2.

Storage Engine

If you run or upgrade to MongoDB 3.0 or higher 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 as long as the server has adequate disk space. Ops Manager does not delete the backup directories once the migration is complete. The backup directories are safe to keep and will not affect any future storage engine conversion, but they do take up disc space. If desired, you can delete them. The backup directories are located in the mongod’s data directory. For 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 single-member replica set, you must give the Automation Agent write access to the MongoDB data directory’s parent directory. The agent creates a temporary backup of the data in parent directory when updating the storage engine.

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

Certain properties of a deployment cannot be changed, including data paths, log paths, ports, and the server assignment for each MongoDB process.

Deployment Topology

You can make modifications at all levels of a deployment’s topology, including child processes. You can also modify the topology itself. To do so use this tutorial or one of the more specific tutorials available in this section of the manual, such as Migrate a Replica Set Member to a New Server or Convert a Standalone to a Replica Set.

Group-Level Modifications

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

Multiple Modifications

You can combine multiple modifications into one deployment. For example, you could make all the following modifications before clicking the Review Changes button:

  • Add the latest stable version of MongoDB to the Version Manager.
  • Enable SSL 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.


To edit the deployment’s configuration:


Click Deployment, then the Processes tab, then the Topology view.


On the line listing the deployment item, click Modify.

A deployment item can be a sharded cluster, a replica set, a member of a sharded cluster or replica set, or a standalone.


Modify deployment settings.

Make changes as appropriate and click Apply. Ops Manager locks fields that you cannot change. To add shards to a cluster or members to a replica set, increase the number or shards or members.

The following table provides information for certain fields:

Auth Schema Version Specifies the schema for storing user data. MongoDB 3.0 uses a different schema for user data than previous versions. For compatibility information, see the MongoDB Release Notes.
Eligible Server RegExp Specifies the servers to which Ops Manager deploys MongoDB. To let Ops Manager select from any of your provisioned servers, enter a period (“.”). To select a specific set of servers, enter their common prefix. To use your local machine, enter the machine name.
Config Server Replica Set Name If you deploy a sharded cluster on MongoDB 3.2 or higher, the config servers deploy as a replica set. This field specifies the name for the replica set.
Member Options Configures replica set members. By default, each member is a voting member that bears data. You can configure a member as an arbiter, hidden, delayed, or having a certain priority in an election.
Index Configuration Creates a MongoDB index. For details, see Create Indexes.
Advanced Options

Configures additional runtime options. For option descriptions, see Advanced Options for MongoDB Deployments.

New in version 3.4: You can set the engine option to inMemory to use an in-memory storage engine per member in your deployment.

If a member using an in-memory storage engine fails or is shut down, it loses all of its data. When that member is restarted, it needs to resychronize all of the data from another member. You can use an in-memory storage engine for multiple members of a replica set or shard.

For more information, see In-Memory Storage Engine in the MongoDB manual.


All members of a replica set do not need to use the same storage engine. You can deploy a replica set with members that use a mix of storage engines, including the in-memory storage engine. If a member using an in-memory storage engine fails or is shut down, it loses all of its data. When that member is restarted, it needs to resychronize all of the data from another member.


Confirm any changes to topology.

If you have added processes to a sharded cluster or replica set, click the Servers tab to view where Ops Manager will deploy the processes. If you wish to move a process to a different server, drag and drop it.


Click Review & Deploy to review your changes.


Review and approve your changes.

Ops Manager displays your proposed changes.

  1. If you are satisfied, click Confirm & Deploy.
  2. Otherwise, click Cancel and you can make additional changes.