Navigation

Downgrade 4.2 Replica Set to 4.0

MongoDB 4.2 is currently in development as part of the 4.1 development series.

警告

While the 4.1-dev-series are available, these versions of MongoDB are for testing purposes only and not for production use.

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.

Create Backup

Optional but Recommended. Create a backup of your database.

Prerequisites

Before downgrading the binaries, you must downgrade the feature compatibility version and remove any 4.2 features incompatible with 4.0 or earlier versions as generally outlined below. These steps are necessary only if featureCompatibilityVersion has ever been set to "4.2".

1. Downgrade Feature Compatibility Version (fCV)

Tip

  1. Connect a mongo shell to the primary.

  2. Downgrade the featureCompatibilityVersion to "4.0".

    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.

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

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

All members should return a result that includes:

"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 Backwards Incompatible Persisted Features

Remove all persisted 4.2 features that are incompatible with 4.0.

Unique Index Version

For featureCompatibilityVersion (fCV) set to "4.2", MongoDB uses a new internal format for unique indexes that is incompatible with 4.0. The new format applies to both existing unique indexes as well as newly created/rebuilt unique indexes. Use the following script to drop and recreate all unique indexes.

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

// Obtain a list of unique indexes for both v:1 and v:2
var unique_idx_v1 = [];
var unique_idx_v2 = [];
db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos().forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(i){
         if (i.unique){
            if (i.v === 1) {
               unique_idx_v1.push(i);
            }
            else {
               unique_idx_v2.push(i);
            }
            return;
         }
      });
   });
});

printjson(unique_idx_v1);
printjson(unique_idx_v2);

// Drop and recreate all v:1 indexes
for (let idx of unique_idx_v1) {
   let [dbName, collName] = idx.ns.split(".");
   let res = db.getSiblingDB(dbName).runCommand({dropIndexes: collName, index: idx.name});
   assert.commandWorked(res);
   res = db.getSiblingDB(dbName).runCommand({
      createIndexes: collName,
      indexes: [{"key": idx.key, "name": idx.name, "unique": true, "v": 1}]
   });
   assert.commandWorked(res);
}

// Drop and recreate all v:2 indexes
for (let idx of unique_idx_v2) {
   let [dbName, collName] = idx.ns.split(".");
   let res = db.getSiblingDB(dbName).runCommand({dropIndexes: collName, index: idx.name});
   assert.commandWorked(res);
   res = db.getSiblingDB(dbName).runCommand({
      createIndexes: collName,
      indexes: [{"key": idx.key, "name": idx.name, "unique": true, "v": 2}]
   });
   assert.commandWorked(res);
}

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.

Index Name Length

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

Procedure

警告

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 instructions on safely terminating mongod processes.
  2. Replace the 4.2 binary with the 4.0 binary and restart.
  3. Wait for the member to recover to SECONDARY state before downgrading the next secondary. To check the member's state, use the rs.status() method in the mongo shell.
3

Step down the primary.

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

rs.stepDown()

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

4

Replace and restart former primary mongod.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 4.0 binary and start the new instance.