Release Notes >
Release Notes for MongoDB 6.0 (Release Candidate) >
Downgrade 6.0 to 5.0 >
Downgrade 6.0 Sharded Cluster to 5.0

Downgrade 6.0 Sharded Cluster to 5.0¶

On this page

Downgrade Path
Prerequisites
Downgrade Procedure

Before you attempt a downgrade, familiarize yourself with the content in this page.

Downgrade Path¶

Important

Before you upgrade or downgrade a sharded cluster, ensure all sharded cluster members are running. If you do not, the upgrade or downgrade will not complete until all members are started.

After upgrading to 6.0, if you need to downgrade, we recommend downgrading to the latest patch release of 5.0.

Prerequisites¶

Before you begin the downgrade procedure, you must complete the following prerequisite steps.

1. Create Backup¶

Optional but Recommended. Create a backup of your database.

To learn how to create a backup, see MongoDB Backup Methods.

2. Remove Backward-Incompatible Features¶

To downgrade from 6.0 to 5.0, you must remove 6.0 features that are incompatible with 5.0. For a list of incompatible features and how to remove them, see Downgrade Considerations.

3. Ensure No Resharding Operations are in Progress¶

Ensure that any resharding operations have successfully completed. If a recent resharding operation has failed due to a primary failover, you must first run the cleanupReshardCollection command before downgrading the featureCompatibilityVersion of your sharded cluster.

If a resharding operation is still running while you downgrade the featureCompatibilityVersion of your sharded cluster, the resharding operation will not complete.

4. Downgrade Feature Compatibility Version (fCV)¶

To downgrade the fCV of your sharded cluster:

Ensure that no initial sync is in progress. Running the setFeatureCompatibilityVersion command while an initial sync is in progress causes the initial sync to restart.
Ensure that no nodes have a newlyAdded field in their replica set configuration. Run the following command on each node in your replica set to verify this:
copy
```
use local
db.system.replset.find( { "members.newlyAdded" : { $exists : true } } );
```
The newlyAdded field only appears in a node’s replica set configuration document during and shortly after an initial sync.
Ensure that no replica set member is in the ROLLBACK or RECOVERING state.
Use mongosh to connect to your mongos instance.
Downgrade the featureCompatibilityVersion to "5.0".
copy
```
db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )
```
The setFeatureCompatibilityVersion command performs writes to an internal system collection and is idempotent. If the command does not complete successfully, retry the command on the mongos instance.
Note

Troubleshooting
- While setFeatureCompatibilityVersion is running on the sharded cluster, chunk migrations, splits, and merges can fail with ConflictingOperationInProgress.
- If setFeatureCompatibilityVersion fails with a ManualInterventionRequired error, and the cluster has recently undergone a resharding operation that had failed due to an election, you must run the cleanupReshardCollection command before you attempt to run setFeatureCompatibilityVersion again.
To ensure that all members of the replica set have the updated featureCompatibilityVersion, connect to each replica set member and check the featureCompatibilityVersion:
copy
```
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
```
Tip

Access Control

For a sharded cluster that has access control enabled, to run the adminCommand on a shard replica set member, you must connect to the member as a shard local user.

All members should return a result that includes:
copy
```
"featureCompatibilityVersion" : { "version" : "5.0" }
```
If any member returns a featureCompatibilityVersion of "6.0", wait for the member to return version "5.0" before proceeding.

For more information on the returned featureCompatibilityVersion value, see View FeatureCompatibilityVersion.

Downgrade Procedure¶

Warning

Before proceeding with the downgrade procedure, ensure that all sharded cluster members, including delayed replica set members, have the prerequisite changes. To do that, check the featureCompatibilityVersion and the remove the incompatible features for each node before downgrading.

← Downgrade 6.0 Replica Set to 5.0 Upgrade 5.0 to 6.0 →