Downgrade 4.4 Sharded Cluster to 4.2

1. Namespace Length

Starting in MongoDB 4.4:

• For featureCompatibilityVersion set to "4.4" or greater, MongoDB raises the limit for unsharded collections and views to 255 bytes, and to 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>),

• For featureCompatibilityVersion set to "4.2" or earlier, the maximum length of unsharded collections and views namespace remains 120 bytes and 100 bytes for sharded 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.

2. Downgrade Feature Compatibility Version (fCV)

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.

For more information on the returned featureCompatibilityVersion value, see Get 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.

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.

4. Remove 4.4 Features

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

• If any view definitions that include 4.4 operators, such as $unionWith or $function. See also New Aggregation Operators.

• Unhide or drop hidden indexes.

5. Update Missing Shard Keys

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.

6. Update Shard Keys That Exceed 512 bytes

Downgrade a Sharded Cluster

sh.stopBalancer()

sh.getBalancerState()

sh.startBalancer()