Downgrade MongoDB 3.4 to 3.2
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.
Remove 3.4 Incompatible Features
To downgrade, you must 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"
.
For instructions specific to standalone, replica set, or sharded cluster, see:
1. Downgrade Feature Compatibility Version
Downgrade the featureCompatibilityVersion
to "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 target 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.
To find views, you can run the following in the mongo
shell:
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.
To find collections with collation specifications, you can run the
following in the mongo
shell:
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:
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
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.
To find indexes with v: 2
, you can run the following in the
mongo
shell:
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); } }); }); });