Navigation
This is an upcoming (i.e. in progress) version of the manual.

Downgrade 4.4 Replica Set to 4.2

MongoDB 4.4 Release Candidates

While the 4.4 release candidates 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.4, if you need to downgrade, we recommend downgrading to the latest patch release of 4.2.

Downgrade Floor

If you need to downgrade form version 4.4, downgrade to 4.2.6 or later version. You cannot downgrade to a 4.2.5 or earlier version.

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.

1. Namespace Length

Starting in MongoDB 4.4:

  • For featureCompatibilityVersion set to "4.4" or greater, MongoDB raises the limit on collection/view namespace to 255 bytes. For a collection or a view, the namespace includes the database name, the dot (.) separator, and the collection/view name (e.g. <database>.<collection>),
  • For featureCompatibilityVersion set to "4.2" or earlier, the maximum length of the collection/view namespace remains 120 bytes.

Before downgrading, resolve any collections or views with namespaces that exceed the 120-byte Namespace Length limit for Feature Compatibility Version (fCV) 4.2.

To determine if you have any collections or views with namespaces that exceed the 120-byte limit, connect mongo shell to the primary and run:

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

   mdb.getCollectionInfos( ).forEach(function(c){
      namespace = d.name + "." + c.name
      namespacelenBytes =  encodeURIComponent(namespace).length

      if (namespacelenBytes > 120) {
         print (c.type.toUpperCase() + " namespace exceeds 120 bytes:: " + namespace )
      }
   } )
})

If any collection or view namespace exceeds 120 bytes, then prior to downgrading the fCV:

  • Rename the collection using the renameCollection command.
  • For views, use db.createView() to recreate the view using a shorter name, then drop the original view.

2. Downgrade Feature Compatibility Version (fCV)

Tip

To downgrade the featureCompatibilityVersion of your sharded cluster:

  1. Connect a mongo shell to the primary.

  2. Downgrade the featureCompatibilityVersion to "4.2".

    db.adminCommand({setFeatureCompatibilityVersion: "4.2"})
    

    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:

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

    All members should return a result that includes:

    "featureCompatibilityVersion" : { "version" : "4.2" }
    

    If any member returns a featureCompatibilityVersion of "4.4", wait for the member to reflect version "4.2" before proceeding.

For more information on the returned featureCompatibilityVersion value, see View FeatureCompatibilityVersion.

3. Remove FCV 4.4 Persisted Features

The following steps are necessary only if fCV has ever been set to "4.4".

Remove all persisted 4.4 features that are incompatible with 4.2. These include:

Compound Hashed Indexes

Remove all compound hashed indexes.

Use db.collection.getIndexes() to identify any compound hashed indexes in a collection and use db.collection.dropIndex() to remove those indexes.

4. Remove 4.4 Features

Remove all persisted features that use 4.4 features. These include but are not limited to:

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.2 binaries.

Using either a package manager or a manual download, get the latest release in the 4.2 series. If using a package manager, add a new repository for the 4.2 binaries, then perform the actual downgrade process.

Once upgraded to 4.4, if you need to downgrade, we recommend downgrading to the latest patch release of 4.2.

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.

    db.adminCommand( { shutdown: 1 } )
    
  2. Replace the 4.4 binary with the 4.2 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.

  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.

    db.adminCommand( { shutdown: 1 } )
    
  2. Delete the contents of the arbiter data directory. The storage.dbPath configuration setting or --dbpath command line option specify the data directory of the arbiter mongod.

    rm -rf /path/to/mongodb/datafiles/*
    
  3. Replace the 4.4 binary with the 4.2 binary and restart.

  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.

rs.stepDown()

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

5

Replace and restart former primary mongod.

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

  1. Shut down the previous primary.

    db.adminCommand( { shutdown: 1 } )
    
  2. Replace the mongod binary with the 4.2 binary and restart.