On this page本页内容
Before you attempt any downgrade, familiarize yourself with the content of this document.
Once upgraded to 4.2, if you need to downgrade, we recommend downgrading to the latest patch release of 4.0.
Tip
If you downgrade,
Starting in MongoDB 4.2, change streams are available regardless of the "majority"
read concern support; that is, read concern majority
support can be either enabled (default) or disabled to use change streams.
In MongoDB 4.0 and earlier, change streams are available only if "majority"
read concern support is enabled (default).
Once you downgrade to 4.0-series, change streams will be disabled if you have disabled read concern "majority"
.
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. These include:
Tip
setFeatureCompatibilityVersion
command while an initial sync is in progress will cause the initial sync to restart.ROLLBACK
or RECOVERING
state.To downgrade the featureCompatibilityVersion
of your sharded cluster:
mongo
shell to the primary.featureCompatibilityVersion
to "4.0"
.
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.2"
, wait for the member to reflect version "4.0"
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.2"
.
Remove all persisted 4.2 features that are incompatible with 4.0.
Starting in MongoDB 4.2, for featureCompatibilityVersion
(fCV)
set to "4.2"
or greater, MongoDB removes the Index Key Limit
. For fCV set to "4.0"
, the limit still applies.
If you have an index with keys that exceed the Index Key Limit
once fCV is set to "4.0"
, consider changing the index to a hashed index or to indexing a computed value. You can also temporarily use failIndexKeyTooLong
set to false
before resolving the problem. However, with failIndexKeyTooLong
set to false
, queries that use these indexes can return incomplete results.
Starting in MongoDB 4.2, for featureCompatibilityVersion
(fCV)
set to "4.2"
or greater, MongoDB removes the Index Name Length
. For fCV set to "4.0"
, the limit still applies.
If you have an index with a name that exceeds the Index Name Length
once fCV is set to "4.0"
, drop and recreate the index with a shorter name.
With featureCompatibilityVersion
(fCV) "4.2"
, MongoDB uses a new internal format for unique indexes that is incompatible with MongoDB 4.0. The new internal format applies to both existing unique indexes as well as newly created/rebuilt unique indexes.
If fCV has ever been set to "4.2"
, use the following script to drop and recreate all unique indexes.
Tip
Perform this operation after you have resolved any index key size and index name length issues first.
user_1_db_1
System Unique Index¶In addition, if you have enabled access control, you must also remove the system unique index user_1_db_1
on the admin.system.users
collection.
If fCV has ever been set to "4.2"
, use the following command to drop the user_1_db_1
system unique index:
The user_1_db_1
index will automatically be rebuilt when starting the server with the 4.0 binary in the procedure below.
For featureCompatibilityVersion
(fCV) set to "4.2"
, MongoDB supports creating Wildcard Indexes. You must drop all wildcard indexes before downgrading to fCV "4.0"
.
Use the following script to drop and recreate all wildcard indexes:
Important
Downgrading to fCV "4.0"
during an in-progress wildcard index build does not automatically drop or kill the index build. The index build can complete after downgrading to fcv "4.0"
, resulting in a valid wildcard index on the collection. Starting the 4.0 binary against against that data directory will result in startup failures.
Use db.currentOp()
to check for any in-progress wildcard index builds. Once any in-progress wildcard index builds complete, run the script to drop them before downgrading to fCV "4.0"
.
Before downgrading the binaries, modify read-only view definitions and collection validation definitions that include the 4.2 operators, such as $set
, $unset
, $replaceWith
.
$set
stage, use the $addFields
stage instead.$replaceWith
stage, use the $replaceRoot
stage instead.$unset
stage, use the $project
stage instead.You can modify a view either by:
db.myview.drop()
method) and recreating the view (db.createView()
method) orcollMod
command.You can modify the colleciton validation expressions by:
collMod
command.tls
-Prefixed Configuration¶Starting in MongoDB 4.2, MongoDB adds "tls"
-prefixed options as aliases for the "ssl"-prefixed
options.
If your deployments or clients use the "tls"
-prefixed options, replace with the corresponding "ssl"-prefixed
options for the mongod, the mongos, and the mongo shell and drivers.
zstd
Compression¶zstd
Data Compression¶Important
If you also use zstd Journal Compression, perform these steps after you perform the prerequisite steps for the journal compressor.
The zstd compression library is available starting in version 4.2. For any member that has data stored using zstd compression, the downgrade procedure will require an initial sync for that member. To prepare:
data directory
for the mongod
instance. This directory will be used in the downgrade procedure below.
Important
Ensure that the user account running mongod
has read and write permissions for the new directory.
storage.wiredTiger.collectionConfig.blockCompressor
to use the default compressor (snappy
) or set to another 4.0 supported compressor.storage.dbPath
to the new data directory.Repeat for any other members that used zstd compression.
zstd
Journal Compression¶The zstd compression library is available for journal data compression starting in version 4.2.
For any member that uses zstd library for its journal compressor:
zstd
for journal compression and data compression,storage.wiredTiger.engineConfig.journalCompressor
to use the default compressor (snappy
) or set to another 4.0 supported compressor.zstd
for journal compression only,Note
The following procedure involves restarting the replica member as a standalone without the journal.
mongod
instance:
storage.journal.enabled
to false
.disableLogicalSessionCacheRefresh
to true
in the setParameter
section.For example:例如:
If you use command-line options instead of a configuration file, you will have to update the command-line option during the restart.
mongod
instance:
--nojournal
option--replSet
):disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.mongod
instance:
Confirm that the process is no longer running.
storage.journal.enabled
setting.disableLogicalSessionCacheRefresh
parameter.storage.wiredTiger.engineConfig.journalCompressor
setting to use the default journal compressor or specify a new value.For example:例如:
If you use command-line options instead of a configuration file, you will have to update the command-line options during the restart below.
mongod
instance as a replica set member:
--nojournal
option.--wiredTigerJournalCompressor
command-line option to use the default journal compressor or update to a new value.disableLogicalSessionCacheRefresh
parameter.zstd
Network Compression¶The zstd compression library is available for network message compression starting in version 4.2.
To prepare for the downgrade:
net.compression.compressors
setting to prepare for the restart during the downgrade procedure.
zstd
in its URI connection string
, update to remove zstd
from the list.mongo
shell that specifies zstd
in its --networkMessageCompressors
, update to remove zstd
from the list.Important
Messages are compressed when both parties enable network compression. Otherwise, messages between the parties are uncompressed.
Important
Remove client-side field level encryption code in applications prior to downgrading the server.
MongoDB 4.2 adds support for enforcing client-side field level encryption as part of a collection’s JSON Schema document validation. Specifically, the $jsonSchema
object supports the encrypt
and encryptMetadata
keywords. MongoDB 4.0 does not support these keywords and fails to start if any collection specifies those keywords as part of its validation $jsonSchema
.
Use db.getCollectionInfos()
on each database to identify collections specifying automatic field level encryption rules as part of the $jsonSchema
validator. To prepare for downgrade, connect to the replica set primary and perform either of the following operations for each collection using the 4.0-incompatible keywords:
collMod
to modify the collection’s validator
and replace the $jsonSchema
with a schema that contains only 4.0-compatible document validation syntax:
-or-
collMod
to remove the validator
object entirely:
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.0 series. If using a package manager, add a new repository for the 4.0 binaries, then perform the actual downgrade process.
Once upgraded to 4.2, if you need to downgrade, we recommend downgrading to the latest patch release of 4.0.
Downgrade each secondary member of the replica set, one at a time:
mongod
. See Stop mongod Processes for additional ways to safely terminate mongod
processes.
Note
If you use command-line options instead of a configuration file, update the command-line options as appropriate during the restart.
mongod
instance used zstd
data compression,--dbpath
to the new directory (created during the prerequisites).--wiredTigerCollectionBlockCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance used zstd
journal compression,--wiredTigerJournalCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance included zstd
network message compression,--networkMessageCompressors
to enable message compression using the default snappy,zlib
compressors. Alternatively, explicitly specify the compressor(s).SECONDARY
state. To check the member’s state, connect a mongo
shell to the member and run rs.status()
method.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
.
Note
If you use command-line options instead of a configuration file, update the command-line options as appropriate during the restart.
mongod
instance used zstd
data compression,--dbpath
to the new directory (created during the prerequisites).--wiredTigerCollectionBlockCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance used zstd
journal compression,--wiredTigerJournalCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance included zstd
network message compression,--networkMessageCompressors
to enable message compression using the default snappy,zlib
compressors. Alternatively, explicitly specify the compressor(s).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.
When rs.status()
shows that the primary has stepped down and another member has assumed PRIMARY
state:
mongod
binary with the 4.0 binary and restart.
Note
If you use command-line options instead of a configuration file, update the command-line options as appropriate during the restart.
mongod
instance used zstd
data compression,--dbpath
to the new directory (created during the prerequisites).--wiredTigerCollectionBlockCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance used zstd
journal compression,--wiredTigerJournalCompressor
to use the default snappy
compressor (or, alternatively, explicitly set to a 4.0 supported compressor).mongod
instance included zstd
network message compression,--networkMessageCompressors
to enable message compression using the default snappy,zlib
compressors. Alternatively, explicitly specify the compressor(s).