Downgrade 3.6 Sharded Cluster to 3.4¶

On this page

Downgrade Path
Create Backup
Considerations
Prerequisites
Procedure

Before you attempt any downgrade, familiarize yourself with the content of this document.

Downgrade Path¶

Once upgraded to 3.6, if you need to downgrade, we recommend downgrading to the latest patch release of 3.4.

Create Backup¶

Optional but Recommended. Create a backup of your database.

Considerations¶

While the downgrade is in progress, you cannot make changes to the collection metadata. For example, during the downgrade, do not do any of the following:

sh.enableSharding()
sh.shardCollection()
sh.addShard()
db.createCollection()
db.collection.drop()
db.dropDatabase()
any operation that creates a database
any other operation that modifies the cluster metadata in any way. See Sharding Reference for a complete list of sharding commands. Note, however, that not all commands on the Sharding Reference page modify the cluster metadata.

Prerequisites¶

Before downgrading the binaries, you must downgrade the feature compatibility version and remove any 3.6 features incompatible with 3.4 or earlier versions as outlined below. These steps are necessary only if featureCompatibilityVersion has ever been set to "3.6".

1. Downgrade Feature Compatibility Version¶

Connect a mongo shell to the mongos instance.
Downgrade the featureCompatibilityVersion to "3.4".
copy
```
db.adminCommand({setFeatureCompatibilityVersion: "3.4"})
```
The setFeatureCompatibilityVersion command performs writes to an internal system collection and is idempotent. If for any reason the command does not complete successfully, retry the command on the mongos instance.

To ensure that all members of the sharded cluster reflect the updated featureCompatibilityVersion, connect to each shard replica set member and each config server replica set member and check the featureCompatibilityVersion:

Tip

For a sharded cluster that has access control enabled, to run the following command against a shard replica set member, you must connect to the member as a shard local user.

copy

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

All members should return a result that includes:

copy

"featureCompatibilityVersion" : { "version" : "3.4" }

If any member returns a featureCompatibilityVersion that includes either a version value of "3.6" or a targetVersion field, wait for the member to reflect version "3.4" before proceeding.

For more information on the returned featureCompatibilityVersion value, see View FeatureCompatibilityVersion.

2. Remove Backwards Incompatible Persisted Features¶

Remove all persisted features that are incompatible with 3.4. For example, if you have defined any any view definitions, document validators, and partial index filters that use 3.6 query features such as $jsonSchema or $expr, you must remove them.

Procedure¶

Downgrade a Sharded Cluster¶

Warning

Before proceeding with the downgrade procedure, ensure that all members, including delayed replica set members in the sharded cluster, reflect the prerequisite changes. That is, check the featureCompatibilityVersion and the removal of incompatible features for each node before downgrading.

1

Download the latest 3.4 binaries.¶

Using either a package manager or a manual download, get the latest release in the 3.4 series. If using a package manager, add a new repository for the 3.4 binaries, then perform the actual downgrade process.

Once upgraded to 3.6, if you need to downgrade, we recommend downgrading to the latest patch release of 3.4.

2

Disable the Balancer.¶

Turn off the balancer as described in Disable the Balancer.

3

Downgrade the `mongos` instances.¶

Downgrade the binaries and restart.

4

Downgrade each shard, one at a time.¶

Downgrade the shards one at a time. If the shards are replica sets, for each shard:

Downgrade the secondary members of the replica set one at a time:
1. Perform a clean shut down of the mongod process.
  
  Note
  
  If you do not perform a clean shut down, errors may result that prevent the mongod process from starting.
  
  Forcibly terminating the mongod process may cause inaccurate results for db.collection.count() and db.stats() as well as lengthen startup time the next time that the mongod process is restarted.
  
  This applies whether you attempt to terminate the mongod process from the command line via kill or similar, or whether you use your platform’s initialization system to issue a stop command, like sudo systemctl stop mongod or sudo service mongod stop.
2. Replace the 3.6 binary with the 3.4 binary.
3. Start the 3.4 binary with the --shardsvr and --port command line options. Include any other configuration as appropriate for your deployment, e.g. --bind_ip.
  copy
  mongod --shardsvr --port <port> --dbpath <path> \ --bind_ip localhost,<hostname(s)|ip address(es)>
  Or if using a configuration file, update the file to include sharding.clusterRole: shardsvr, net.port, and any other configuration as appropriate for your deployment, e.g. net.bindIp, and start:
  copy
  sharding: clusterRole: shardsvr net: port: <port> bindIp: localhost,<hostname(s)|ip address(es)> storage: dbpath: <path>
4. Wait for the member to recover to SECONDARY state before downgrading the next secondary member. To check the member’s state, you can issue rs.status() in the mongo shell.
  
  Repeat for each secondary member.
Step down the replica set primary.

Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:
copy
```
rs.stepDown()
```
When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, downgrade the stepped-down primary:
1. Shut down the stepped-down primary and replace the mongod binary with the 3.4 binary.
2. Start the 3.4 binary with the --shardsvr and --port command line options. Include any other configuration as appropriate for your deployment, e.g. --bind_ip.
  copy
  mongod --shardsvr --port <port> --dbpath <path> --bind_ip localhost,<hostname(s)|ip address(es)>
  Or if using a configuration file, update the file to include sharding.clusterRole: shardsvr, net.port, and any other configuration as appropriate for your deployment, e.g. net.bindIp, and start the 3.4 binary:
  copy
  sharding: clusterRole: shardsvr net: port: <port> bindIp: localhost,<hostname(s)|ip address(es)> storage: dbpath: <path>

5

Downgrade the config servers.¶

If the config servers are replica sets:

Downgrade the secondary members of the replica set one at a time:
1. Shut down the secondary mongod instance and replace the 3.6 binary with the 3.4 binary.
2. Start the 3.4 binary with both the --configsvr and --port options. Include any other configuration as appropriate for your deployment, e.g. --bind_ip.
  copy
  mongod --configsvr --port <port> --dbpath <path> --bind_ip localhost,<hostname(s)|ip address(es)>
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr, net.port, and any other configuration as appropriate for your deployment, e.g. net.bindIp, and start the 3.4 binary:
  copy
  sharding: clusterRole: configsvr net: port: <port> bindIp: localhost,<hostname(s)|ip address(es)> storage: dbpath: <path>
  Include any other configuration as appropriate for your deployment.
3. Wait for the member to recover to SECONDARY state before downgrading the next secondary member. To check the member’s state, issue rs.status() in the mongo shell.
  
  Repeat for each secondary member.
Step down the replica set primary.
1. Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:
  copy
  rs.stepDown()
2. When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the stepped-down primary and replace the mongod binary with the 3.4 binary.
3. Start the 3.4 binary with both the --configsvr and --port options. Include any other configuration as appropriate for your deployment, e.g. --bind_ip.
  copy
  mongod --configsvr --port <port> --dbpath <path> --bind_ip localhost,<hostname(s)|ip address(es)>
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr, net.port, and any other configuration as appropriate for your deployment, e.g. net.bindIp, and start the 3.4 binary:
  copy
  sharding: clusterRole: configsvr net: port: <port> bindIp: localhost,<hostname(s)|ip address(es)> storage: dbpath: <path>

6

Re-enable the balancer.¶

Once the downgrade of sharded cluster components is complete, re-enable the balancer.

← Downgrade 3.6 Replica Set to 3.4 Release Notes for MongoDB 3.4 →