Navigation

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.

Note

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.

Considerations

MongoDB Version

To choose which versions of MongoDB are available to Cloud 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.

      Example

      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.

Downgrade Limitations

Downgrading from 3.6

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

Downgrading from 3.4

  • You may not downgrade a MongoDB deployment from version 3.4 to any version before 3.2.8.
  • Cloud 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 later and modify the MongoDB storage engine, Cloud Manager shuts down and restarts the MongoDB process. For a multi-member replica set, Cloud Manager performs a rolling initial sync of each member.

Cloud 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. Cloud 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 Cloud Manager generates.

Before you can change the storage engine for a standalone instance or 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

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

You can modify the following deployment settings:

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:

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

Prerequisites

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

Procedure

To edit the deployment’s configuration:

1

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

2

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.

3

Modify deployment settings.

Make changes as appropriate and click Apply. Cloud 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 Cloud Manager deploys MongoDB. To let Cloud 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.

Important

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.

4

Confirm any changes to topology.

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

5

Click Review & Deploy to review your changes.

6

Click Confirm & Deploy to deploy your changes.

Otherwise, click Cancel and you can make additional changes.