On this page本页内容
Before you attempt any downgrade, familiarize yourself with the content of this document.
Once upgraded to 4.4, if you need to downgrade, we recommend downgrading to the latest patch release of 4.2.
Downgrade Floor
If you need to downgrade form version 4.4, downgrade to 4.2.6 or a later version. You cannot downgrade to 4.2.5 or an earlier version.
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 4.2 to 4.0, you must remove incompatible features that are persisted and/or update incompatible configuration settings.
Starting in MongoDB 4.4:
"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>
),"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:
If any collection or view namespace exceeds 120 bytes, then prior to downgrading the fCV:
renameCollection
command.db.createView()
to recreate the view using a shorter name, then drop the original view.Tip
setFeatureCompatibilityVersion
command while an initial sync is in progress will cause the initial sync to restart.ROLLBACK
or RECOVERING
state.replSetReconfig
to remove the term
field from the configuration document and blocks until the new configuration propagates to a majority of replica set members.To downgrade the featureCompatibilityVersion
of your sharded cluster:
mongo
shell to the primary.featureCompatibilityVersion
to "4.2"
.
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.
featureCompatibilityVersion
, connect to each replica set member and check the featureCompatibilityVersion
:
All members should return a result that includes:
If any member returns a featureCompatibilityVersion
of "4.4"
, wait for the member to reflect version "4.2"
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 "4.4"
.
Remove all persisted 4.4 features that are incompatible with 4.2. These include:
Remove all compound hashed indexes.
Use db.collection.getIndexes()
to identify any compound hashed indexes in a collection and use db.collection.dropIndex()
to remove those indexes.
Remove all persisted features that use 4.4 features. These include but are not limited to:
$unionWith
or $function
. See also New Aggregation Operators.Unhide
or drop
hidden indexes.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.
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.
Once upgraded to 4.4, if you need to downgrade, we recommend downgrading to the latest patch release of 4.2.
Downgrade each secondary member of the replica set, one at a time:
mongod
.
SECONDARY
state before downgrading the next secondary. To check the member’s state, use the rs.status()
method in the mongo
shell.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:
mongod
. See Stop mongod Processes for additional ways to safely terminate mongod
processes.
storage.dbPath
configuration setting or --dbpath
command line option specify the data directory of the arbiter mongod
.
ARBITER
state. To check the member’s state, connect a mongo
shell to the member and run rs.status()
method.Use rs.stepDown()
in the mongo
shell to step down the primary and force the normal failover procedure.
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:
mongod
binary with the 4.2 binary and restart.