Downgrade 4.4 Standalone to 4.2
Before you attempt any downgrade, familiarize yourself with the content of this document.
Downgrade Path
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.
Create Backup
Optional but Recommended. Create a backup of your database.
Access Control
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.
Prerequisites
To downgrade from 4.4 to 4.2, you must remove incompatible features that are persisted and/or update incompatible configuration settings. These include:
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 the mongod
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:
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)
To downgrade the featureCompatibilityVersion
of your standalone:
Connect a
mongo
shell to themongod
instance.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 themongod
instance.
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 usedb.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:
If any view definitions that include 4.4 operators, such as
$unionWith
or$function
. See also New Aggregation Operators.
Procedure
Warning
Before proceeding with the downgrade procedure, ensure that the prerequisites have been completed.
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.
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.
Shut down the mongod
instance.
To cleanly shut down the mongod
process, connect a
mongo
shell to the instance and run:
db.adminCommand( { shutdown: 1 } )
A clean shutdown of a
mongod
completes all pending operations,
flushes all data to data files, and closes all data files.
Restart with the latest 4.2 mongod
instance.
Replace the 4.4 binary with the downloaded 4.2
mongod
binary and restart.