Docs Menu

Downgrade 4.2 Standalone to 4.0

On this page

  • Downgrade Path
  • Create Backup
  • Access Control
  • 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.

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

Tip

If you downgrade,

  • On Windows, downgrade to version 4.0.12 or later version. You cannot downgrade to a 4.0.11 or earlier version.
  • On Linux/macOS, if you are running change streams and want to seamlessly resume change streams, downgrade to 4.0.7 or later versions.

Optional but Recommended. Create a backup of your database.

If your deployment 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.

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

To downgrade the featureCompatibilityVersion of your standalone:

  1. Connect a mongo shell to the mongod instance.
  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 mongod instance.

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

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

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> }
}
Tip
See:

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.

Tip

Perform this operation after you have resolved any index key size and index name length issues first.

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

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

Downgrading to fCV "4.0" during an in-progress wildcard index build does not automatically drop or kill the index build. The index build can complete after downgrading to fcv "4.0", resulting in a valid wildcard index on the collection. Starting the 4.0 binary against against that data directory will result in startup failures.

Use db.currentOp() to check for any in-progress wildcard index builds. Once any in-progress wildcard index builds complete, run the script to drop them before downgrading to fCV "4.0".

Before downgrading the binaries, modify read-only view definitions and collection validation definitions that include the 4.2 operators, such as $set, $unset, $replaceWith.

You can modify a view either by:

You can modify the colleciton validation expressions by:

Starting in MongoDB 4.2, MongoDB adds "tls"-prefixed options as aliases for the "ssl"-prefixed options.

If your deployments or clients use the "tls"-prefixed options, replace with the corresponding "ssl"-prefixed options for the mongod, the mongos, and the mongo shell and drivers.

The zstd compression library is available starting in version 4.2.

If your standalone has any data using zstd compression:

Tip

Perform this step after all the other prerequisite steps have been performed.

  1. Stop all writes to your instance.
  2. Create a mongodump of your database before starting the downgrade; mongodump outputs uncompressed data.

    mongodump --host=<myhost> --port=<port> --out=mystandalone.uncompressed.fcv4.0

    Include any other options, such as --username, --password, and --authenticationDatabase if your standalone enforces access control.

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

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

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

If the mongod instance uses zstd library for its journal compressor:

Note

If you encounter an unclean shutdown for a mongod during the downgrade procedure such that you need to use the journal files to recover, recover the instance using the 4.2 mongod and then retry the downgrade of the instance.

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

To prepare for the downgrade:

  1. For the mongod 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.
Important

Messages are compressed when both parties enable network compression. Otherwise, messages between the parties are uncompressed.

Important

Remove client-side field level encryption code in applications prior to downgrading the server.

MongoDB 4.2 adds support for enforcing client-side field level encryption as part of a collection's JSON Schema document validation. Specifically, the $jsonSchema object supports the encrypt and encryptMetadata keywords. MongoDB 4.0 does not support these keywords and fails to start if any collection specifies those keywords as part of its validation $jsonSchema.

Use db.getCollectionInfos() on each database to identify collections specifying automatic field level encryption rules as part of the $jsonSchema validator. To prepare for downgrade, do either of the following operations for each collection using the 4.0-incompatible keywords:

Warning

Before proceeding with the downgrade procedure, ensure that the prerequisites have been completed.

1

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.

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.

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

2
  1. Shut down your mongod instance. To safely terminate the mongod process, you can connect a mongo shell to the instance and run:

    db.adminCommand( { shutdown: 1 } )

    For additional methods to safely terminate your mongod instance, see Stop mongod Processes.

  2. Replace the 4.2 binary with the downloaded 4.0 mongod binary and restart.

    Note

    If you use command-line options instead of a configuration file, update the command-line options as appropriate during the restart.

    • If your command-line options include "tls"-prefixed options, update to "ssl"-prefixed options.
    • If the mongod instance used zstd data compression,

    • If the mongod instance used zstd journal compression,

    • If the mongod instance included zstd network message compression,

      • Remove --networkMessageCompressors to enable message compression using the default snappy,zlib compressors. Alternatively, explicitly specify the compressor(s).
3

Skip this step if you have not downgraded from a standalone that used zstd compression.

If you have downgraded from a standalone that used zstd, you have created a dump of your data as a prerequisite. Use mongorestore to restore that data to your 4.0 standalone.

mongorestore --host=<myhost> --port=<port> mystandalone.uncompressed.fcv4.0
Give Feedback
© 2021 MongoDB, Inc.

About

  • Careers
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2021 MongoDB, Inc.