• Release Notes >
• Release Notes for MongoDB 4.2 >
• Downgrade 4.2 to 4.0 >
• Downgrade 4.2 Replica Set to 4.0

Downgrade 4.2 Replica Set to 4.0

Before you attempt any downgrade, familiarize yourself with the content of this document.

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

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".

Create Backup

Optional but Recommended. Create a backup of your database.

Access Control

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.

Prerequisites

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

1. Downgrade Feature Compatibility Version (fCV)

Tip

• Ensure that no initial sync is in progress. Running setFeatureCompatibilityVersion command while an initial sync is in progress will cause the initial sync to restart.
• Ensure that no replica set member is in ROLLBACK or RECOVERING state.

To downgrade the featureCompatibilityVersion of your sharded cluster:

1. Connect a mongo shell to the primary.

2. Downgrade the featureCompatibilityVersion to "4.0".

   copy

   db.adminCommand({setFeatureCompatibilityVersion: "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.

3. To ensure that all members of the replica set reflect the updated featureCompatibilityVersion, connect to each replica set member and check the featureCompatibilityVersion:

   copy

   db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
   

   All members should return a result that includes:

   copy

   "featureCompatibilityVersion" : { "version" : "4.0" }
   

   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.

2. Remove FCV 4.2 Persisted Features

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.

2a. Index Key Size

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.

2b. Index Name Length

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.

copy

db.collection.dropIndex( <name | index specification> )

db.collection.createIndex(
   { <index specification> },
   { name: <shorter name> }
}

See

db.collection.dropIndex() and db.collection.createIndex()

2c. Unique Index Version

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.

Script

copy

// A script to rebuild unique indexes after downgrading fcv 4.2 to 4.0.
// Run this script to drop and recreate unique indexes
// for backwards compatibility with 4.0.

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);

   mdb.getCollectionInfos( { type: "collection" } ).forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);

      currentCollection.getIndexes().forEach(function(idx){
         if (idx.unique){
            print("Dropping and recreating the following index:" + tojson(idx))

            assert.commandWorked(mdb.runCommand({dropIndexes: c.name, index: idx.name}));

            let res = mdb.runCommand({ createIndexes: c.name, indexes: [idx] });
            if (res.ok !== 1)
               assert.commandWorked(res);
         }
      });
   });
});

2d. Remove Wildcard Indexes

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:

copy

// A script to drop wildcard indexes before downgrading fcv 4.2 to 4.0.
// Run this script to drop wildcard indexes
// for backwards compatibility with 4.0.

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos({ type: "collection" }).forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(idx){

         var key = Object.keys(idx.key);
         if (key[0].includes("$**")) {

           print("Dropping index: " + idx.name + " from " + idx.ns);

           let res = mdb.runCommand({dropIndexes: currentCollection, index: idx.name});
           assert.commandWorked(res);

         }

      });
   });
});

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".

2e. View Definitions/Collection Validation Definitions that Include 4.2 Operators

Before downgrading the binaries, modify read-only view definitions and collection validation definitions that include the 4.2 operators, such as $set, $unset, $replaceWith.

• For the $set stage, use the $addFields stage instead.
• For the $replaceWith stage, use the $replaceRoot stage instead.
• For the $unset stage, use the $project stage instead.

You can modify a view either by:

• dropping the view (db.myview.drop() method) and recreating the view (db.createView() method) or
• using the collMod command.

You can modify the colleciton validation expressions by:

• using the collMod command.

3. Update 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.

4. Prepare Downgrade from 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:

1. Create a new empty 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.

2. If you use a configuration file, update the file to prepare for the downgrade procedure:

   1. Delete storage.wiredTiger.collectionConfig.blockCompressor to use the default compressor (snappy) or set to another 4.0 supported compressor.
   2. Update storage.dbPath to the new data directory.
   If you use command-line options instead, you will have to update the options in the procedure below.

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:

If the member uses zstd for journal compression and data compression,

• If using a configuration file, delete storage.wiredTiger.engineConfig.journalCompressor to use the default compressor (snappy) or set to another 4.0 supported compressor.
• If using command-line options instead, you will have to update the options in the procedure below.

If the member uses zstd for journal compression only,

Note

The following procedure involves restarting the replica member as a standalone without the journal.

1. Perform a clean shutdown of the mongod instance:

   copy

   db.getSiblingDB('admin').shutdownServer()
   

2. Update the configuration file to prepare to restart as a standalone:

   • Set storage.journal.enabled to false.
   • Comment out the replication settings for your deployment.
   • Set parameter disableLogicalSessionCacheRefresh to true in the setParameter section.

   For example:

   copy

   storage:
      journal:
         enabled: false
   #replication:
   #   replSetName: replA
   setParameter:
       disableLogicalSessionCacheRefresh: true
   

   If you use command-line options instead of a configuration file, you will have to update the command-line option during the restart.

3. Restart the mongod instance:

   • If you are using a configuration file:

     copy

     mongod -f <path/to/myconfig.conf>
     

   • If you are using command-line options instead of a configuration file,

     • Include the --nojournal option
     • Remove any replication command-line options (such as --replSet):
     • Set parameter disableLogicalSessionCacheRefresh to true in the --setParameter option.
     copy

     mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true  ...
     

4. Perform a clean shutdown of the mongod instance:

   copy

   db.getSiblingDB('admin').shutdownServer()
   

   Confirm that the process is no longer running.

5. Update the configuration file to prepare to restart as a replica set member with the new journal compressor:

   • Remove the storage.journal.enabled setting.
   • Uncomment the replication settings for your deployment.
   • Remove the disableLogicalSessionCacheRefresh parameter.
   • Remove storage.wiredTiger.engineConfig.journalCompressor setting to use the default journal compressor or specify a new value.

   For example:

   copy

   storage:
      wiredTiger:
         engineConfig:
            journalCompressor: <newValue>
   replication:
      replSetName: replA
   

   If you use command-line options instead of a configuration file, you will have to update the command-line options during the restart below.

6. Restart the mongod instance as a replica set member:

   • If you are using a configuration file:

     copy

     mongod -f <path/to/myconfig.conf>
     

   • If you are using command-line options instead of a configuration file:

     • Remove the --nojournal option.
     • Remove the --wiredTigerJournalCompressor command-line option to use the default journal compressor or update to a new value.
     • Include your replication command-line options as well as any additional options for your replica set member.
     • Remove the disableLogicalSessionCacheRefresh parameter.
     copy

     mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...
     

Note

If you encounter an unclean shutdown for a mongod during the downgrade procedure such that you need to use the journal files to recover, recover the instance using the 4.2 mongod and then retry the downgrade of the instance.

zstd Network Compression

The zstd compression library is available for network message compression starting in version 4.2.

To prepare for the downgrade:

1. For any replica set member that uses zstd for network message compression and uses a configuration file, update the net.compression.compressors setting to prepare for the restart during the downgrade procedure.

   If you use command-line options instead, you will have to update the options in the procedure below.

2. For any client that specifies zstd in its URI connection string, update to remove zstd from the list.

3. For any 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.

5. Remove Client-Side Field Level Encryption Document Validation Keywords

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:

• Use collMod to modify the collection’s validator and replace the $jsonSchema with a schema that contains only 4.0-compatible document validation syntax:

  copy

  db.runCommand({
    "collMod" : "<collection>",
    "validator" : {
      "$jsonSchema" : { <4.0-compatible schema object> }
    }
  })
  

  -or-

• Use collMod to remove the validator object entirely:

  copy

  db.runComand({ "collMod" : "<collection>", "validator" : {} })
  

Procedure

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.

1

Download the latest 4.0 binaries.

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.

2

Downgrade secondary members of the replica set.

Downgrade each secondary member of the replica set, one at a time:

1. Shut down the mongod. See Stop mongod Processes for additional ways to safely terminate mongod processes.

   copy

   db.adminCommand( { shutdown: 1 } )
   

2. Replace the 4.2 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.

   • If your command-line options include “tls”-prefixed options, update to “ssl”-prefixed options.
   • If the mongod instance used zstd data compression,
     • Update --dbpath to the new directory (created during the prerequisites).
     • Remove --wiredTigerCollectionBlockCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance used zstd journal compression,
     • Remove --wiredTigerJournalCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance included zstd network message compression,
     • Remove --networkMessageCompressors to enable message compression using the default snappy,zlib compressors. Alternatively, explicitly specify the compressor(s).

3. Wait for the member to recover to SECONDARY state. To check the member’s state, connect a mongo shell to the member and run rs.status() method.

4. Once the member is in SECONDARY stage, downgrade the next secondary.

3

Downgrade arbiter replica set member, if any.

Skip this step if the replica set does not include an arbiter.

Downgrade the arbiter member of the replica set:

1. Shut down the mongod. See Stop mongod Processes for additional ways to safely terminate mongod processes.

   copy

   db.adminCommand( { shutdown: 1 } )
   

2. Delete the arbiter data directory contents. The storage.dbPath configuration setting or --dbpath command line option specify the data directory of the arbiter mongod.

   copy

   rm -rf /path/to/mongodb/datafiles/*
   

3. Replace the 4.2 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.

   • If your command-line options include “tls”-prefixed options, update to “ssl”-prefixed options.
   • If the mongod instance used zstd data compression,
     • Update --dbpath to the new directory (created during the prerequisites).
     • Remove --wiredTigerCollectionBlockCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance used zstd journal compression,
     • Remove --wiredTigerJournalCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance included zstd network message compression,
     • Remove --networkMessageCompressors to enable message compression using the default snappy,zlib compressors. Alternatively, explicitly specify the compressor(s).

4. Wait for the member to recover to ARBITER state. To check the member’s state, connect a mongo shell to the member and run rs.status() method.

4

Step down the primary.

Use rs.stepDown() in the mongo shell to step down the primary and force the normal failover procedure.

copy

rs.stepDown()

rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.

5

Replace and restart the former primary.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state:

1. Shut down the previous primary.

   copy

   db.adminCommand( { shutdown: 1 } )
   

2. Replace the 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.

   • If your command-line options include “tls”-prefixed options, update to “ssl”-prefixed options.
   • If the mongod instance used zstd data compression,
     • Update --dbpath to the new directory (created during the prerequisites).
     • Remove --wiredTigerCollectionBlockCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance used zstd journal compression,
     • Remove --wiredTigerJournalCompressor to use the default snappy compressor (or, alternatively, explicitly set to a 4.0 supported compressor).
   • If the mongod instance included zstd network message compression,
     • Remove --networkMessageCompressors to enable message compression using the default snappy,zlib compressors. Alternatively, explicitly specify the compressor(s).

←   Downgrade 4.2 Standalone to 4.0 Downgrade 4.2 Sharded Cluster to 4.0  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.