Downgrade 3.4 Sharded Cluster to 3.2

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

Downgrade Path

Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlierversion. 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 featurecompatibility version and remove any 3.4 features incompatible with 3.2 or earlier versions as outlinedbelow. These steps are necessary only iffeatureCompatibilityVersion 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".

  1. 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, youcan safely retry the command on the mongos instance as the operation isidempotent.

2. Remove Views

If you have defined any views, drop the views before downgradingMongoDB 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:

  1. db.adminCommand("listDatabases").databases.forEach(function(d){
  2.    let mdb = db.getSiblingDB(d.name);
  3.    mdb.getCollectionInfos({type: "view"}).forEach(function(c){
  4.       print(mdb[c.name]);
  5.    });
  6. });

In each database that contains views, drop the system.viewscollection to drop all views in that database.

If running with access control, you must have privileges to drop thesystem.views collection for the database. SeeCreate 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 anindex, remove the collection or index before downgrading MongoDB 3.4 to3.2.

  • Connect a mongo shell to the mongos instance.

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

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

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

  • To find indexes with collation specification, you can run thefollowing in the mongo shell:
  1. db.adminCommand("listDatabases").databases.forEach(function(d){
  2.    let mdb = db.getSiblingDB(d.name);
  3.    mdb.getCollectionInfos().forEach(function(c){
  4.       let currentCollection = mdb.getCollection(c.name);
  5.       currentCollection.getIndexes().forEach(function(i){
  6.          if (i.collation){
  7.             printjson(i);
  8.          }
  9.       });
  10.    });
  11. });

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 versionsof MongoDB earlier than 3.4, operations against documents thatcontain decimal type may fail. For somepossible conversion options, seeModel Monetary Data.

To detect the presence of decimal, you can rundb.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 indexescreated in MongoDB 3.4 if featureCompatibilityVersion: "3.4"),reindex the collection to recreateall indexes on the collection as v: 1 before downgrading MongoDB.

You must perform this operation on both the shards and the configservers:

  • Connect a mongo shell to the mongos instance.

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

  1. db.adminCommand("listDatabases").databases.forEach(function(d){
  2.    let mdb = db.getSiblingDB(d.name);
  3.    mdb.getCollectionInfos().forEach(function(c){
  4.       let currentCollection = mdb.getCollection(c.name);
  5.       currentCollection.getIndexes().forEach(function(i){
  6.          if (i.v === 2){
  7.             printjson(i);
  8.          }
  9.       });
  10.    });
  11. });
  • If a shard is a replica set, repeat this procedure on each member ofthe shard as the reindex operation does not propagate to thesecondaries.

Tip

If connecting a mongo shell to a secondary member, setrs.slaveOk().

  • 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 thecollection metadata. For example, during the downgrade, donot do any of the following:

Downgrade a Sharded Cluster

Download the latest 3.2 binaries.

Using either a package manager or a manual download, get the latestrelease in the 3.2 series. If using a package manager, add a newrepository for the 3.2 binaries, then perform the actual downgradeprocess.

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

Disable the Balancer.

Turn off the balancer as described inDisable the Balancer.

Downgrade the mongos instances.

Downgrade the binaries and restart.

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 secondarymembers of the replica set one at a time:

    • Shut down the mongod instance and replace the 3.4binary with the 3.2 binary.

    • Start the 3.2 binary with the —shardsvr and—port command line options.

  1. mongod --shardsvr --port <port> --dbpath <path>

Of if using a configuration file, update the file toinclude sharding.clusterRole: shardsvr and net.port and start:

  1. sharding:
  2.    clusterRole: shardsvr
  3. net:
  4.    port: <port>
  5. storage:
  6.    dbpath: <path>

Include any other configuration as appropriate for your deployment.

  • Wait for the member to recover to SECONDARY state beforedowngrading the next secondary member. To check the member’sstate, you can issue rs.status() in themongo shell.

Repeat for each secondary member.

  • Step down the replica set primary.

Connect a mongo shell to the primary and users.stepDown() to step down the primary and force anelection of a new primary:

  1. rs.stepDown()

  • When rs.status()shows that the primary has stepped down and another memberhas assumed PRIMARY state, downgrade the stepped-down primary:

    • Shut down the stepped-down primary and replace themongod binary with the 3.2 binary.

    • Start the 3.2 binary with the —shardsvr and—port command line options.

  1. mongod --shardsvr --port <port> --dbpath <path>

Or if using a configuration file, update the file tospecify sharding.clusterRole: shardsvr and net.port and start the3.2 binary:

  1. sharding:
  2.    clusterRole: shardsvr
  3. net:
  4.    port: <port>
  5. storage:
  6.    dbpath: <path>

Include any other configuration as appropriate for your deployment.

Downgrade the config servers.

If the config servers are replica sets:

  • Downgrade the secondarymembers of the replica set one at a time:

    • Shut down the secondary mongod instance and replacethe 3.4 binary with the 3.2 binary.

    • Start the 3.2 binary with both the —configsvr and—port options:

  1. mongod --configsvr --port <port> --dbpath <path>

If using a configuration file, update the file tospecify sharding.clusterRole: configsvr and net.port and start the3.4 binary:

  1. sharding:
  2.    clusterRole: configsvr
  3. net:
  4.    port: <port>
  5. storage:
  6.    dbpath: <path>

Include any other configuration as appropriate for your deployment.

  • Wait for the member to recover to SECONDARY state beforedowngrading 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.

    • Connect a mongo shell to the primary and users.stepDown() to step down the primary and force anelection of a new primary:
  1. rs.stepDown()

  • When rs.status() shows that the primary has steppeddown and another member has assumed PRIMARY state, shut downthe stepped-down primary and replace the mongod binarywith the 3.2 binary.

  • Start the 3.2 binary with both the —configsvr and—port options:

  1. mongod --configsvr --port <port> --dbpath <path>

If using a configuration file, update the file tospecify sharding.clusterRole: configsvr and net.port and start the3.4 binary:

  1. sharding:
  2.    clusterRole: configsvr
  3. net:
  4.    port: <port>
  5. storage:
  6.    dbpath: <path>

Include any other configuration as appropriate for your deployment.

Re-enable the balancer.

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