Downgrade MongoDB 3.4 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.

Remove 3.4 Incompatible Features

To downgrade, you must remove any 3.4 features incompatible with 3.2 or earlier versions as generallyoutlined below. These steps are necessary only iffeatureCompatibilityVersion has ever been set to "3.4".

For instructions specific to standalone, replica set,or sharded cluster, see:

1. Downgrade Feature Compatibility Version

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 target as the operation isidempotent.

2. Remove Views

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

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.

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

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.

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. });

Procedures