Downgrade 5.0 Standalone to 4.4¶

On this page

Downgrade Path
Create Backup
Access Control
Prerequisites
Procedure

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

Downgrade Path¶

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

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 5.0 to 4.4, you must remove incompatible features that are persisted and/or update incompatible configuration settings. These include:

1. Cluster Default Read and Write Concerns¶

MongoDB 5.0 changed the default value for cluster-wide read and write concerns, and downgrading to MongoDB 4.4 might change those defaults back. Consider manually configuring your cluster’s default read and write concern before downgrading:

To manually configure a default value for a cluster’s read or write concern, use the setDefaultRWConcern command.
If your cluster includes an arbiter, and you had previously disabled "Majority" read concern to prevent cache pressure in certain situations, you may want to configure --enableMajorityReadConcern false or replication.enableMajorityReadConcern: false once you downgrade.

2. Document Fields with `.` or `$` Characters¶

MongoDB 5.0 adds support for including the . or $ characters in document field names. You must delete any documents containing field names that include the . or $ characters before downgrading to MongoDB 4.4.

3. Slim-format Timezone Data Files¶

MongoDB 5.0 enables support for slim-format timezone data files. If using slim-format timezone data files in your deployment, as provided to MongoDB with the --timeZoneInfo command line option or processManagement.timeZoneInfo configuration file setting, you must downgrade to MongoDB 4.4.7 or later, or else revert your timezone data files to use the previous non-slim-format data files.

4. Downgrade Feature Compatibility Version (fCV)¶

To downgrade the featureCompatibilityVersion of your standalone:

Connect a mongo shell to the mongod instance.
Downgrade the featureCompatibilityVersion to "4.4".
copy
```
db.adminCommand({setFeatureCompatibilityVersion: "4.4"})
```
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.

5. Remove fCV 5.0 Persisted Features¶

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

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

Time-series Collections

Remove all time series collections.

Runtime Audit Filter Management

Disable Runtime Audit Filter Management by setting auditLog.runtimeConfiguration to false in the node’s configuration file.
Update the audit filters for this instance in the local configuration file.

6. Remove 5.0 Features¶

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

If any view definitions include 5.0 operators, such as $dateAdd or $sampleRate, they must be removed. See New Aggregation Operators for the full list.

Procedure¶

Warning

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

1

Download the latest 4.4 binaries.¶

Using either a package manager or a manual download, get the latest release in the 4.4 series. If using a package manager, add a new repository for the 4.4 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 5.0, if you need to downgrade, we recommend downgrading to the latest patch release of 4.4.

2

Shut down the `mongod` instance.¶

To cleanly shut down the mongod process, connect mongosh to the instance and run:

copy

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.

3

Update configuration files.¶

Disable any configurable 5.0 features by updating the mongod instance’s configuration file before restarting.

4

Restart with the latest 4.4 `mongod` instance.¶

Replace the 5.0 binary with the downloaded 4.4 mongod binary and restart.

← Downgrade 5.0 to 4.4 Downgrade 5.0 Replica Set to 4.4 →