- Release Notes >
- Release Notes for MongoDB 4.2 >
- Downgrade 4.2 to 4.0
Downgrade 4.2 to 4.0¶
On this page
The following page summarizes various considerations for downgrading to 4.0. For specific instructions for your deployment type, see:
- Downgrade 4.2 Standalone to 4.0.
- Downgrade 4.2 Replica Set to 4.0.
- Downgrade 4.2 Sharded Cluster to 4.0.
Downgrade Path¶
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,
- On Windows, downgrade to version 4.0.12 or later version. You cannot downgrade to a 4.0.11 or earlier version.
- On Linux/macOS, if you are running change streams and want to seamlessly resume change streams, downgrade to 4.0.7 or later versions.
Considerations for Replica Sets and Sharded Clusters¶
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).
If you have disabled read concern "majority", change streams will be
disabled once you downgrade to 4.0-series.
Create Backup¶
Optional but Recommended. Create a backup of your database.
Prequisites¶
To downgrade from 4.2 to 4.0, you must remove incompatible features that are persisted and/or update incompatible configuration settings. These include:
Downgrade Feature Compatibility Version (fCV)¶
Before downgrading the binaries, you must downgrade the
featureCompatibilityVersion (fCV) to “4.0” and remove all persisted
fCV 4.2 features that are incompatible with 4.0, such as:
- Indexes with a name that exceeds the
Index Name Lengthlimit. - Indexes with keys that exceeds the
Index Key Limit. - Unique Indexes with new internal format.
- Wildcard Indexes.
- Read-only view definitions and collection validation definition that include 4.2 operators.
For specific instructions to downgrade the fCV and remove these features, see:
zstd Compression¶
Using zstd for data compression, journal compression, or network messages requires additional considerations for downgrades.
For detailed instructions appropriate for your deployment type, see:
tls-Prefixed Configurations¶
Before downgrading the binaries, update tls-prefixed configuration
options for ssl-prefixed aliases.
For detailed instructions appropriate for your deployment type, see:
Remove Client Side Field Level Encryption Document Validation Keywords¶
Before downgrading binaries, remove any
automatic encryption rule keywords from collection
$jsonSchema validation objects.
For detailed instructions appropriate for your deployment type, see: