Docs Menu
Docs Home
/
MongoDB Manual
/ / /

Downgrade 6.0 Replica Set to 5.0

On this page

  • Downgrade Path
  • Access Control
  • Prerequisites
  • Downgrade Procedure

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

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 6.0, downgrade to the latest patch release of 5.0.

MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release.

For example, you may downgrade a 6.0-series to a 5.0-series deployment. However, further downgrading that 5.0-series deployment to a 4.4-series deployment is not supported.

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.

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

Optional but Recommended. Create a backup of your database.

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

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.

To downgrade the fCV of your replica set:

  1. 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.

  2. 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:

    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.

  3. Ensure that no replica set member is in the ROLLBACK or RECOVERING state.

  4. Use mongosh to connect to your primary.

  5. Downgrade the featureCompatibilityVersion to "5.0".

    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 primary.

  6. To ensure that all members of the replica set have the updated featureCompatibilityVersion, connect to each replica set member and check the featureCompatibilityVersion:

    db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

    All members should return a result that includes:

    "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 Get FeatureCompatibilityVersion.

Warning

Before proceeding with the downgrade procedure, ensure that all replica set 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.

1

Using either a package manager or a manual download, get the latest release in the 5.0 series. If using a package manager, add a new repository for the 5.0 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 6.0, downgrade to the latest patch release of 5.0.

2

Ensure that the 5.0 binaries are in your System PATH. To confirm your binary version, run the following command:

mongod --version

The command output should indicate a 5.0-series release.

3

Downgrade each secondary member of the replica set, one at a time:

1

To shut down the mongod process, use mongosh to connect to the secondary and run the following command:

db.adminCommand( { shutdown: 1 } )
2

To start a mongod process, run the following command:

mongod --dbpath </path-to-data-folder>

To learn more about starting a mongod process, see Start mongod Processes.

3

Before downgrading the next secondary, wait for the member to recover to the SECONDARY state. To check the member's state, use the rs.status() method in mongosh.

4
4

Skip this step if the replica set does not include an arbiter.

Downgrade the arbiter member of the replica set:

1

To shutdown the arbiter, use mongosh to connect to the arbiter and run the following command:

db.adminCommand( { shutdown: 1 } )
2

To find the data directory of the arbiter mongod, check either the storage.dbPath configuration setting or --dbpath command line option.

Run the following command:

rm -rf /path/to/mongodb/datafiles/*
3

To start a mongod process, run the following command:

mongod --dbpath </path-to-mongodb-datafiles>

To learn more about starting a mongod process, see Start mongod Processes.

4

Before downgrading the primary, wait for the member to recover to the ARBITER state. To check the member's state, use the rs.status() method in mongosh.

5
1

In mongosh, use rs.stepDown() to step down the primary and force the normal failover procedure.

rs.stepDown()
2

Run the following command:

rs.status()

Verify that the primary has stepped down and another member has assumed the PRIMARY state.

3
1

To perform a shutdown of the primary, use mongosh to connect to the primary and run the following command:

db.adminCommand( { shutdown: 1 } )
2

To start a mongod process, run the following command:

mongod --dbpath </path-to-mongodb-datafiles>

To learn more about starting a mongod process, see Start mongod Processes.

Back

Downgrade 6.0 Standalone to 5.0