Before you attempt any downgrade, familiarize yourself with the content of this document.
Downgrade Path
Important
Before you upgrade or downgrade a replica set, ensure all replica set members are running. If you do not, the upgrade or downgrade will not complete until all members are started.
If you need to downgrade from 4.4, downgrade to the latest patch release of 4.2.
MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release. You may downgrade a 4.4-series to a 4.2-series deployment, however, further downgrading that 4.2-series deployment to a 4.0-series deployment is not supported.
Warning
Downgrade Floor
If you need to downgrade from version 4.4, downgrade to 4.2.6 or a later version. You cannot downgrade to 4.2.5 or an earlier version.
Create Backup
Optional but Recommended. Create a backup of your database.
Access Control
If your replica set has access control enabled, your downgrade user
privileges must include privileges to list and manage indexes across
databases. A user with root role has the required
privileges.
Prerequisites
Remove Incompatible Features
To downgrade from 4.4 to 4.2, you must remove incompatible features that are persisted and/or update incompatible configuration settings.
1. Namespace Length
Starting in MongoDB 4.4:
For featureCompatibilityVersion set to
"4.4"or greater, MongoDB raises the limit on collection/view namespace to 255 bytes. For a collection or a view, the namespace includes the database name, the dot (.) separator, and the collection/view name (e.g.<database>.<collection>),For featureCompatibilityVersion set to
"4.2"or earlier, the maximum length of the collection/view namespace remains 120 bytes.
Before downgrading, resolve any collections or views with namespaces that exceed the 120-byte Namespace Length limit for Feature Compatibility Version (fCV) 4.2.
To determine if you have any collections or views with namespaces
that exceed the 120-byte limit, connect mongo shell
to the primary and run:
db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos( ).forEach(function(c){ namespace = d.name + "." + c.name namespacelenBytes = encodeURIComponent(namespace).length if (namespacelenBytes > 120) { print (c.type.toUpperCase() + " namespace exceeds 120 bytes:: " + namespace ) } } ) })
If any collection or view namespace exceeds 120 bytes, then prior to downgrading the fCV:
Rename the collection using the
renameCollectioncommand.For views, use
db.createView()to recreate the view using a shorter name, then drop the original view.
2. Downgrade Feature Compatibility Version (fCV)
Tip
Ensure that no initial sync is in progress. Running
setFeatureCompatibilityVersioncommand while an initial sync is in progress will cause the initial sync to restart.Ensure that no replica set member is in
ROLLBACKorRECOVERINGstate.Downgrading to featureCompatibilityVersion (fCV) : "4.2" implicitly performs a
replSetReconfigto remove thetermfield from the configuration document and blocks until the new configuration propagates to a majority of replica set members.
To downgrade the featureCompatibilityVersion of your replica set:
Connect a
mongoshell to the primary.Downgrade the
featureCompatibilityVersionto"4.2".db.adminCommand({setFeatureCompatibilityVersion: "4.2"}) The
setFeatureCompatibilityVersioncommand performs writes to an internal system collection and is idempotent. If for any reason the command does not complete successfully, retry the command on the primary.To ensure that all members of the replica set reflect the updated
featureCompatibilityVersion, connect to each replica set member and check thefeatureCompatibilityVersion:db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) All members should return a result that includes:
"featureCompatibilityVersion" : { "version" : "4.2" } If any member returns a
featureCompatibilityVersionof"4.4", wait for the member to reflect version"4.2"before proceeding.
For more information on the returned featureCompatibilityVersion
value, see View FeatureCompatibilityVersion.
Note
Arbiters do not replicate the admin.system.version collection.
Because of this, arbiters always have a feature compatibility version equal
to the downgrade version of the binary, regardless of the fCV value of the
replica set.
For example, an arbiter in a MongoDB 4.4 cluster, has an fCV value of 4.2.
3. Remove fCV 4.4 Persisted Features
The following steps are necessary only if fCV has ever been set to
"4.4".
Remove all persisted 4.4 features that are incompatible with 4.2. These include:
- Compound Hashed Indexes
Remove all compound hashed indexes.
Use
db.collection.getIndexes()to identify any compound hashed indexes in a collection and usedb.collection.dropIndex()to remove those indexes.
4. Remove 4.4 Features
Remove all persisted features that use 4.4 features. These include but are not limited to:
If any view definitions that include 4.4 operators, such as
$unionWithor$function. See also New Aggregation Operators.
Confirm Clean Shutdown
When a step prompts you to stop your deployment, ensure your
mongod instance is
shut down.
Procedure
Warning
Before proceeding with the downgrade procedure, ensure that all
replica set members, including delayed replica set members, reflect
the prerequisite changes. That is, check the
featureCompatibilityVersion and the removal of incompatible
features for each node before downgrading.
Download the latest 4.2 binaries.
Using either a package manager or a manual download, get the latest release in the 4.2 series. If using a package manager, add a new repository for the 4.2 binaries, then perform the actual downgrade process.
Important
Before you upgrade or downgrade a replica set, ensure all replica set members are running. If you do not, the upgrade or downgrade will not complete until all members are started.
If you need to downgrade from 4.4, downgrade to the latest patch release of 4.2.
Downgrade secondary members of the replica set.
Downgrade each secondary member of the replica set, one at a time:
Run the following command from the
mongoshell to perform a clean shutdown, or refer to StopmongodProcesses for additional ways to safely terminate themongodprocess:db.adminCommand( { shutdown: 1 } ) Replace the 4.4 binary with the 4.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.Once the member is in
SECONDARYstage, downgrade the next secondary.
Downgrade arbiter replica set member, if any.
Skip this step if the replica set does not include an arbiter.
Downgrade the arbiter member of the replica set:
Run the following command from the
mongoshell to perform a clean shutdown, or refer to StopmongodProcesses for additional ways to safely terminate themongodprocess:db.adminCommand( { shutdown: 1 } ) Delete the contents of the arbiter data directory. The
storage.dbPathconfiguration setting or--dbpathcommand line option specify the data directory of the arbitermongod.rm -rf /path/to/mongodb/datafiles/* Replace the 4.4 binary with the 4.2 binary and restart.
Wait for the member to recover to
ARBITERstate. To check the member's state, connect amongoshell to the member and runrs.status()method.
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:
Run the following command from the
mongoshell to perform a clean shutdown, or refer to StopmongodProcesses for additional ways to safely terminate themongodprocess:db.adminCommand( { shutdown: 1 } ) Replace the
mongodbinary with the 4.2 binary and restart.