Downgrade 6.0 Replica Set to 5.0
Before you attempt a downgrade, familiarize yourself with the content in this page.
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 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. 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.
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
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. Downgrade Feature Compatibility Version (fCV)
To downgrade the fCV of your replica set:
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: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
orRECOVERING
state.Use
mongosh
to connect to your primary.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.To ensure that all members of the replica set have 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" : "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.
Downgrade Procedure
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.
Download the latest 5.0 binaries.
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.
Downgrade secondary members of the replica set.
Downgrade each secondary member of the replica set, one at a time:
Restart the member.
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.
Wait for the member to enter the SECONDARY
state.
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
.
Downgrade the 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:
Shut down the member.
To shutdown the arbiter, use mongosh
to
connect to the arbiter and run the following command:
db.adminCommand( { shutdown: 1 } )
Delete the contents of the arbiter data directory.
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/*
Restart the arbiter.
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.
Wait for the member to enter the ARBITER
state.
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
.
Downgrade the primary.
Step down the primary.
In mongosh
, use rs.stepDown()
to
step down the primary and force the normal failover
procedure.
rs.stepDown()
Replace and restart the former primary mongod
.
Shut down the member.
To perform a shutdown of the primary, use
mongosh
to connect to the primary and
run the following command:
db.adminCommand( { shutdown: 1 } )
Restart mongod
with the 5.0 binary.
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.