Downgrade 3.4 Replica Set to 3.2
On this page
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 generally outlined below. These steps are necessary only if featureCompatibilityVersion has ever been set  to "3.4".
1. Downgrade Feature Compatibility Version
- 
Connect a mongoshell to the primary.
- 
Downgrade the featureCompatibilityVersionto"3.2".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 primary 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 mongoshell to the primary.
- 
To find views, you can run the following in the mongoshell: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.viewscollection to drop all views in that database.If running with access control, you must have privileges to drop the system.viewscollection for the database. See Create a Role to Dropsystem.viewsCollection 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 mongoshell to the primary.
- 
To find collections with collation specifications, you can run the following in the mongoshell: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 mongoshell: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 mongoshell to the primary.
- 
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 whenfeatureCompatibilityVersionis"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.
- 
Connect a mongoshell to the primary.
- 
To find indexes with v: 2, you can run the following in themongoshell: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); } }); }); }); 
Repeat the process on secondary members of the replica set as the reindex operation does not propagate to the secondaries.
Tip
If connecting a mongo shell to a secondary member, use db.getMongo() to allow reads from secondaries.
Procedure
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.
Downgrade secondary members of the replica set.
Downgrade each secondary member of the replica set, one at a time:
- 
Shut down the mongod. See StopmongodProcesses for instructions on safely terminatingmongodprocesses.
- 
Replace the 3.4 binary with the 3.2 binary and restart. 
- 
Wait for the member to recover to SECONDARYstate before downgrading the next secondary. To check the member's state, use thers.status()method in themongoshell.
Step down the primary.
Use rs.stepDown() in the mongo shell to step down the primary and force the normal failover procedure.
rs.stepDown()
rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.
Replace and restart former primary mongod.
When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 3.2 binary and start the new instance.