- Manage Deployments >
- Edit a Deployment’s Configuration
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 the top-level, such as a 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.
To choose which versions of MongoDB are available to Ops Manager, see Configure Available MongoDB Versions.
Before changing a deployment’s MongoDB version, consult the following documents for any special considerations or application compatibility issues:
Plan the version change during a predefined maintenance window.
Before applying the change to a production environment, change the MongoDB version on a staging environment that reproduces your production environment. This can help avoid discovering compatibility issues that may result in downtime for your production deployment.
If you downgrade to an earlier version of MongoDB and your MongoDB configuration file includes options that are not part of the earlier MongoDB version, you must perform the downgrade in two phases. First, remove the configuration settings that are specific to the newer MongoDB version, and deploy those changes. Then, update the MongoDB version and deploy that change.
For example, if you are running MongoDB version 3.0 with the
engine option set to
mmapv1, and you wish to downgrade
to MongoDB 2.6, you must first remove the engine option as
MongoDB 2.6 does not include that option.
You may not downgrade a MongoDB deployment from version 3.4 to any
version before 3.2.8. As such, Ops Manager will block users from attempting to
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
mongod‘s data directory. For example, if the data directory was
/data/process, the backup would be
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.
Certain properties of a deployment cannot be changed, including data paths, log paths, ports, and the server assignment for each MongoDB process.
You can make modifications at all levels of a deployment’s topology, including child processes. If you edit a child process, any future related edits to the parent might no longer apply to the child. 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.
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.
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:
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.¶
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.|
Configures additional runtime options. For option descriptions, see Advanced Options for MongoDB Deployments.
For managed deployments running MongoDB 3.0 or later, you can add the engine option in Advanced Options to set which storage engine to use. For information on storage engines, see Storage in the MongoDB manual.
New in version 3.4: You can set the engine option to
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.
- If you are satisfied, click Confirm & Deploy.
- Otherwise, click Cancel and you can make additional changes.