On this page本页内容
Before you attempt any downgrade, familiarize yourself with the content of this document.
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.
Once upgraded to 5.0, if you need to downgrade, we recommend downgrading to the latest patch release of 4.4.
Optional but Recommended. Create a backup of your database.
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.
To downgrade from 5.0 to 4.4, you must remove incompatible features that are persisted and/or update incompatible configuration settings. These include:
MongoDB 5.0 changed the default value for cluster-wide read and write concerns, and downgrading to MongoDB 4.4 might change those defaults back. Consider manually configuring your cluster's default read and write concern before downgrading:
setDefaultRWConcern
command."Majority"
read concern to prevent cache pressure in certain situations, you may want to configure --enableMajorityReadConcern false
or replication.enableMajorityReadConcern: false
once you downgrade..
or $
CharactersMongoDB 5.0 adds support for including the .
or $
characters in document field names. You must delete any documents containing field names that include the .
or $
characters before downgrading to MongoDB 4.4.
MongoDB 5.0 enables support for slim-format timezone data files. If using slim-format timezone data files in your deployment, as provided to MongoDB with the --timeZoneInfo
command line option or processManagement.timeZoneInfo
configuration file setting, you must downgrade to MongoDB 4.4.7 or later, or else revert your timezone data files to use the previous non-slim-format data files.
First, verify the following:
setFeatureCompatibilityVersion
command while an initial sync is in progress will cause 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.
ROLLBACK
or RECOVERING
state.Next, to downgrade the featureCompatibilityVersion
of your replica set:
mongo
shell to the primary.featureCompatibilityVersion
to "4.4"
.db.adminCommand({setFeatureCompatibilityVersion: "4.4"})The
setFeatureCompatibilityVersion
command 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 the featureCompatibilityVersion
:
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
All members should return a result that includes:
"featureCompatibilityVersion" : { "version" : "4.4" }
If any member returns a featureCompatibilityVersion
of "5.0"
, wait for the member to reflect version "4.4"
before proceeding.
For more information on the returned featureCompatibilityVersion
value, see View FeatureCompatibilityVersion.
The following steps are necessary only if fCV has ever been set to "5.0"
.
Remove all persisted 5.0 features that are incompatible with 4.4. These include:
Runtime Audit Filter Management
Reset the defaults on the primary server in the group with db.admin.runCommand
. The primary should be the last configuration server in the group to be updated.
db.admin.runCommand( { setAuditConfig: 1, filter: {}, auditAuthorizationSuccess: false } )
The configuration document can also be removed after downgrade:
config.settings.remove({_id: 'audit'});
auditLog.runtimeConfiguration
to false
in the node's configuration file.Remove all persisted features that use 5.0 features. These include but are not limited to:
$dateAdd
or $sampleRate
, they must be removed. See New Aggregation Operators for the full list.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.
Using either a package manager or a manual download, get the latest release in the 4.4 series. If using a package manager, add a new repository for the 4.4 binaries, then perform the actual downgrade process.
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.
Once upgraded to 5.0, if you need to downgrade, we recommend downgrading to the latest patch release of 4.4.
Downgrade each secondary member of the replica set, one at a time:
mongosh
to perform a clean shutdown, or refer to Stop mongod
Processes for additional ways to safely terminate the mongod
process:db.adminCommand( { shutdown: 1 } )
SECONDARY
state before downgrading the next secondary. To check the member's state, use the rs.status()
method in mongosh
.SECONDARY
stage, downgrade the next secondary.Skip this step if the replica set does not include an arbiter.
Downgrade the arbiter member of the replica set:
mongosh
to perform a clean shutdown, or refer to Stop mongod
Processes for additional ways to safely terminate the mongod
process:db.adminCommand( { shutdown: 1 } )
Delete the contents of the arbiter data directory. The storage.dbPath
configuration setting or --dbpath
command line option specify the data directory of the arbiter mongod
.
rm -rf /path/to/mongodb/datafiles/*
ARBITER
state. To check the member's state, connect mongosh
to the member and run rs.status()
method.Use rs.stepDown()
in mongosh
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.
mongod
.When rs.status()
shows that the primary has stepped down and another member has assumed PRIMARY
state:
mongosh
to perform a clean shutdown, or refer to Stop mongod
Processes for additional ways to safely terminate the mongod
process:db.adminCommand( { shutdown: 1 } )
mongod
binary with the 4.4 binary and restart.