Docs Menu
Docs Home
/
MongoDB Manual
/ /

Downgrade 4.2 to 4.0

On this page

  • Downgrade Path
  • Considerations for Replica Sets and Sharded Clusters
  • Create Backup
  • Prequisites
  • Procedures

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.

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 4.2, downgrade 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.

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.

Optional but Recommended. Create a backup of your database.

To downgrade from 4.2 to 4.0, you must remove incompatible features that are persisted and/or update incompatible configuration settings. These include:

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:

For specific instructions to downgrade the fCV and remove these features, see:

Using zstd for data compression, journal compression, or network messages requires additional considerations for downgrades.

For detailed instructions appropriate for your deployment type, see:

Before downgrading the binaries, update tls-prefixed configuration options for ssl-prefixed aliases.

For detailed instructions appropriate for your deployment type, see:

Before downgrading binaries, remove any automatic encryption rule keywords from collection $jsonSchema validation objects.

For detailed instructions appropriate for your deployment type, see:

Back

Upgrade a Sharded Cluster to 4.2