Downgrade 3.4 Sharded Cluster to 3.2¶

On this page

Downgrade Path
Create Backup
Prerequisites
Procedure

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

Downgrade Path¶

Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlier version. You can only downgrade to a 3.2.8 or later version.

Create Backup¶

Optional but Recommended. Create a backup of your database.

Prerequisites¶

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

1. Downgrade Feature Compatibility Version¶

Connect a mongo shell to the mongos instance.
Downgrade the featureCompatibilityVersion to "3.2".
copy
```
db.adminCommand({setFeatureCompatibilityVersion: "3.2"})
```
This command must perform writes to an internal system collection. If for any reason the command does not complete successfully, you can safely retry the command on the mongos instance as the operation is idempotent.

2. Remove Views¶

If you have defined any views, drop the views before downgrading MongoDB 3.4 to 3.2.

Connect a mongo shell to the mongos instance.
To find views, you can run the following in the mongo shell:
copy
```
db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos({type: "view"}).forEach(function(c){
      print(mdb[c.name]);
   });
});
```
In each database that contains views, drop the system.views collection to drop all views in that database.

If running with access control, you must have privileges to drop the system.views collection for the database. See Create a Role to Drop system.views Collection across Databases.

3. Remove Collation Option from Collections and Indexes¶

If you have defined any non-“simple” collation for a collection or an index, remove the collection or index before downgrading MongoDB 3.4 to 3.2.

Connect a mongo shell to the mongos instance.

To find collections with collation specifications, you can run the following in the mongo shell:

copy

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos( { "options.collation": { $exists: true } } ).forEach(function(c){
      print(mdb[c.name]);
   });
});

You can migrate the content of the collection to a new collection without the collation specification (one way is via the aggregation pipeline stage $out).

To find indexes with collation specification, you can run the following in the mongo shell:

copy

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos().forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(i){
         if (i.collation){
            printjson(i);
         }
      });
   });
});

Drop the indexes with a collation specification. After the downgrade, recreate the dropped indexes.

4. Convert Data of Type Decimal¶

Connect a mongo shell to the mongos instance.
Convert any data of decimal type. In versions of MongoDB earlier than 3.4, operations against documents that contain decimal type may fail. For some possible conversion options, see Model Monetary Data.

To detect the presence of decimal, you can run db.collection.validate(true) against the collections which may contain decimal data.

db.collection.validate(true) reports on decimal data only when featureCompatibilityVersion is "3.2".

5. Downgrade Index Versions¶

If you have v: 2 indexes (i.e. the default version for indexes created in MongoDB 3.4 if featureCompatibilityVersion: "3.4"), reindex the collection to recreate all indexes on the collection as v: 1 before downgrading MongoDB.

You must perform this operation on both the shards and the config servers:

Connect a mongo shell to the mongos instance.

To find indexes with v: 2, you can run the following in the mongo shell:

copy

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos().forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(i){
         if (i.v === 2){
            printjson(i);
         }
      });
   });
});

If a shard is a replica set, repeat this procedure on each member of the shard as the reindex operation does not propagate to the secondaries.

Tip

If connecting a mongo shell to a secondary member, set use db.getMongo().setReadPref('secondary') to allow reads from secondaries.
Repeat the process on each member of the config server replica set.

Procedure¶

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

Downgrade a Sharded Cluster¶

1

Download the latest 3.2 binaries.¶

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

Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlier version. You can only downgrade to a 3.2.8 or later version.

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. Shut down the mongod instance and replace the 3.4 binary with the 3.2 binary.
2. Start the 3.2 binary with the --shardsvr and --port command line options.
  copy
  mongod --shardsvr --port <port> --dbpath <path>
  Of if using a configuration file, update the file to include sharding.clusterRole: shardsvr and net.port and start:
  copy
  sharding: clusterRole: shardsvr net: port: <port> 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, 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.2 binary.
2. Start the 3.2 binary with the --shardsvr and --port command line options.
  copy
  mongod --shardsvr --port <port> --dbpath <path>
  Or if using a configuration file, update the file to specify sharding.clusterRole: shardsvr and net.port and start the 3.2 binary:
  copy
  sharding: clusterRole: shardsvr net: port: <port> storage: dbpath: <path>
  Include any other configuration as appropriate for your deployment.

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.4 binary with the 3.2 binary.
2. Start the 3.2 binary with both the --configsvr and --port options:
  copy
  mongod --configsvr --port <port> --dbpath <path>
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
  copy
  sharding: clusterRole: configsvr net: port: <port> 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.2 binary.
3. Start the 3.2 binary with both the --configsvr and --port options:
  copy
  mongod --configsvr --port <port> --dbpath <path>
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
  copy
  sharding: clusterRole: configsvr net: port: <port> storage: dbpath: <path>
  Include any other configuration as appropriate for your deployment.

6

Re-enable the balancer.¶

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

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

Downgrade 3.4 Sharded Cluster to 3.2¶

Downgrade Path¶

Create Backup¶

Prerequisites¶

1. Downgrade Feature Compatibility Version¶

2. Remove Views¶

3. Remove Collation Option from Collections and Indexes¶

4. Convert Data of Type Decimal¶

5. Downgrade Index Versions¶

Procedure¶

Considerations¶

Downgrade a Sharded Cluster¶

Download the latest 3.2 binaries.¶

Disable the Balancer.¶

Downgrade the mongos instances.¶

Downgrade each shard, one at a time.¶

Downgrade the config servers.¶

Re-enable the balancer.¶

Downgrade the `mongos` instances.¶