Docs Menu
Docs Home
/
MongoDB Manual
/ / /

Downgrade 4.4 Sharded Cluster to 4.2

On this page

  • Downgrade Path
  • Create Backup
  • Prerequisites
  • Procedure

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

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.4, downgrade to the latest patch release of 4.2.

MongoDB only supports single-version downgrades. You cannot downgrade to a release that is multiple versions behind your current release.

For example, you may downgrade a 4.4-series to a 4.2-series deployment. However, further downgrading that 4.2-series deployment to a 4.0-series deployment is not supported.

Warning

Downgrade Floor

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

Optional but Recommended. Create a backup of your database.

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

Starting in MongoDB 4.4:

The namespace length limit for unsharded collections and views is 255 bytes, and 235 bytes for sharded collections. For a collection or a view, the namespace includes the database name, the dot (.) separator, and the collection/view name (e.g. <database>.<collection>).

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 a mongos instance 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:

  • For unsharded collections, rename the collections using the renameCollection command.

  • For sharded collections:

    • Use $merge to a new sharded collection with a shorter name, then drop the original collection.

    • Use mongoexport and mongoimport into a new collection with a shorter name, then drop the original collection.

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

Tip

To downgrade the featureCompatibilityVersion of your sharded cluster:

  1. Connect a mongo shell to the mongos instance.

  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 mongos instance.

    Note

    While setFeatureCompatibilityVersion is running on the sharded cluster, chunk migrations, splits, and merges can fail with ConflictingOperationInProgress.

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

    Tip

    For a sharded cluster that has access control enabled, to run the following command against a shard replica set member, you must connect to the member as a shard local user.

    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.

Note

Arbiters do not replicate the admin.system.version collection. Because of this, arbiters always have a feature compatibility version equal to the downgrade version of the binary, regardless of the fCV value of the replica set.

For example, an arbiter in a MongoDB 4.4 cluster, has an fCV value of 4.2.

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

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.

If any collection is sharded using the compound hashed index, use the guidance listed under Compound Hashed Shard Keys below.

Compound Hashed Shard Keys

Remove any sharded collections which were sharded using a compound hashed shard key.

Use sh.status() to identify sharded collections with a compound hashed shard key and remove those collections.

  • If the collection is empty or if the collection does contain data that requires preservation, use db.collection.drop() to drop the collection.

  • If the collection has data that requires preservation, back up the collection first before using db.collection.drop() to drop the collection. After downgrading the cluster, restore the data into the cluster.

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

In MongoDB 4.4, shard key fields can be missing from documents in a sharded collection.

If you downgrade to 4.2 and a sharded collection contains documents missing shard key fields, 4.2 mongos instances do not return documents that are missing the shard key fields. To avoid this situation, update the documents to includes the missing shard key fields before you downgrade.

To find documents that are missing any part of the shard key, use the $exists operator.

For example, if the collection contacts has the shard key { zipcode: 1 }, to find documents without the zipcode field:

db.contacts.find( { zipcode: { $exists: false } } )

To set the missing shard key field to null for these documents, you can use the db.collection.updateMany() method:

db.contacts.updateMany( { zipcode: { $exists: false } }, { $set: { zipcode: null } } )

If setting the missing shard key field to a non-null value, you cannot use the db.collection.updateMany() method and you must perform the update within a transaction or as a retryable write. For details, see Set Missing Shard Key Fields.

Changed in version 4.4: In version 4.4, MongoDB removes the 512-byte limit on the shard key size. However, for MongoDB 4.2 and earlier, a shard key cannot exceed 512 bytes. Update any shard key value that exceed the 512-byte size limit to be within the 512 byte size limit. To update a document's shard key value, see Change a Document's Shard Key Value.

Warning

Before proceeding with the downgrade procedure, ensure that all members, including delayed replica set members in the sharded cluster, reflect the prerequisite changes. That is, check the featureCompatibilityVersion and the removal of incompatible features for each node before downgrading.

1

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.

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.4, downgrade to the latest patch release of 4.2.

2

Connect a mongo shell to a mongos instance in the sharded cluster, and run sh.stopBalancer() to disable the balancer:

sh.stopBalancer()

Note

If a migration is in progress, the system will complete the in-progress migration before stopping the balancer. You can run sh.isBalancerRunning() to check the balancer's current state.

To verify that the balancer is disabled, run sh.getBalancerState(), which returns false if the balancer is disabled:

sh.getBalancerState()

For more information on disabling the balancer, see Disable the Balancer.

3

Downgrade the binaries and restart.

4

Downgrade the shards one at a time.

  1. Downgrade the shard's secondary members one at a time:

    1. Run the following command in mongosh to perform a clean shutdown, or refer to Stop mongod Processes for additional ways to safely terminate the mongod process:

      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 member. To check the member's state, connect a mongo shell to the shard and run rs.status() method.

      Repeat to downgrade for each secondary member.

  2. Downgrade the shard arbiter, if any.

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

    1. Run the following command in mongosh to perform a clean shutdown, or refer to Stop mongod Processes for additional ways to safely terminate the mongod process:

      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.

  3. Downgrade the shard's primary.

    1. Step down the replica set primary. Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

      rs.stepDown()
    2. Run rs.status().

      rs.status()

      When the status shows that the primary has stepped down and another member has assumed PRIMARY state, proceed.

    3. Run the following command from the mongo shell to perform a clean shutdown of the stepped-down primary, or refer to Stop mongod Processes for additional ways to safely terminate the mongod process:

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

Repeat for the remaining shards.

5
  1. Downgrade the secondary members of the config servers replica set (CSRS) one at a time:

    1. Run the following command in mongosh to perform a clean shutdown, or refer to Stop mongod Processes for additional ways to safely terminate the mongod process:

      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 member. To check the member's state, connect a mongo shell to the shard and run rs.status() method.

      Repeat to downgrade for each secondary member.

  2. Step down the config server primary.

    1. Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

      rs.stepDown()
    2. Run rs.status().

      rs.status()

      When the status shows that the primary has stepped down and another member has assumed PRIMARY state, proceed.

    3. Run the following command from the mongo shell to perform a clean shutdown of the stepped-down primary, or refer to Stop mongod Processes for additional ways to safely terminate the mongod process:

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

6

Once the downgrade of sharded cluster components is complete, connect a mongo shell to a mongos and re-enable the balancer.

sh.startBalancer()

The mongo shell method sh.startBalancer() also enables auto-splitting for the sharded cluster.

Back

Downgrade 4.4 Replica Set to 4.2