Downgrade 4.2 Sharded Cluster to 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.

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

db.collection.createIndex(
   { <index specification> },
   { name: <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.

Script to run on mongos

// 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);
         }
      });
   });
});

Script to run on shards

After you have run the script on mongos, you need to check individual shards if you have created shard local users. That is, if you created maintenance users directly on the shards instead of through mongos, run the script on the primary member of the shard.

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

let mdb = db.getSiblingDB('admin');

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);
      }
   });
});

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:

db.getSiblingDB("admin").getCollection("system.users").dropIndex("user_1_db_1")

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:

// 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);

         }

      });
   });
});

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.

The zstd compression library is available for journal data compression starting in version 4.2.

For any shard or config server member that uses zstd library for its journal compressor:

If the member uses zstd for journal compression and zstd 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 only 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:

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

2. Update the configuration file to prepare to restart as a standalone:
   • Set storage.journal.enabled to false.
   • Set parameter skipShardingConfigurationChecks to true.
   • Set parameter disableLogicalSessionCacheRefresh to true in the setParameter section.
   • Comment out the replication settings for your deployment.
   • Comment out the sharding.clusterRole setting.
   • Set the net.port to the member’s current port, if it is not explicitly set.

   For example:例如：

   storage:
      journal:
         enabled: false
   setParameter:
      skipShardingConfigurationChecks: true
      disableLogicalSessionCacheRefresh: true
   #replication:
   #   replSetName: shardA
   #sharding:
   #   clusterRole: shardsvr
   net:
     port: 27218

   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:

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

   • If you are using command-line options instead of a configuration file:
     • Include the --nojournal option.
     • Set parameter skipShardingConfigurationChecks to true.
     • Set parameter disableLogicalSessionCacheRefresh to true in the --setParameter option.
     • Remove any replication command-line options (such as --replSet).
     • Remove --shardsvr/--configsvr option.
     • Explicitly include --port set to the instance’s current port.

     mongod --nojournal --setParameter skipShardingConfigurationChecks=true --setParameter disableLogicalSessionCacheRefresh=true --port <samePort> ...

4. Perform a clean shutdown of the mongod instance:

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

   Confirm that the process is no longer running.

5. Update the configuration file to prepare to restart with the new journal compressor:
   • Remove the storage.journal.enabled setting.
   • Remove the skipShardingConfigurationChecks parameter setting.
   • Remove the disableLogicalSessionCacheRefresh parameter setting.
   • Uncomment the replication settings for your deployment.
   • Uncomment the sharding.clusterRole setting.
   • Remove storage.wiredTiger.engineConfig.journalCompressor setting to use the default journal compressor or specify a new value.

   For example:例如：

   storage:
      wiredTiger:
         engineConfig:
            journalCompressor: <newValue>
   replication:
      replSetName: shardA
   sharding:
      clusterRole: shardsvr
   net:
     port: 27218

   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:

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

   • If you are using command-line options instead of a configuration file:
     • Remove the --nojournal option.
     • Remove the skipShardingConfigurationChecks parameter setting.
     • Remove the disableLogicalSessionCacheRefresh parameter setting.
     • Remove the --wiredTigerJournalCompressor command-line option to use the default journal compressor or update to a new value.
     • Include --shardsvr/--configsvr option.
     • Include your replication command-line options as well as any additional options for your replica set member.

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

The zstd compression library is available starting in version 4.2. For any config server member or shard 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.

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

To prepare for the downgrade:

1. For any mongod/mongos instance 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.