Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

Downgrade 4.0 Replica Set to 3.6

On this page

  • Downgrade Path
  • Create Backup
  • Prerequisites
  • Procedure

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

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

MongoDB 4.0 introduces new hex-encoded string change stream resume tokens:

The resume token _data type depends on the MongoDB versions and, in some cases, the feature compatibility version (fcv) at the time of the change stream's opening/resumption (i.e. a change in fcv value does not affect the resume tokens for already opened change streams):

MongoDB Version
Feature Compatibility Version
Resume Token _data Type
MongoDB 4.0.7 and later
"4.0" or "3.6"
Hex-encoded string (v1)
MongoDB 4.0.6 and earlier
Hex-encoded string (v0)
MongoDB 4.0.6 and earlier
MongoDB 3.6
  • When downgrading from MongoDB 4.0.7 or greater, clients cannot use the resume tokens returned from the 4.0.7+ deployment. To resume a change stream, clients will need to use a pre-4.0.7 upgrade resume token (if available). Otherwise, clients will need to start a new change stream.

  • When downgrading from MongoDB 4.0.6 or earlier, clients can use BinData resume tokens returned from the 4.0 deployment, but not the v0 tokens.

Optional but Recommended. Create a backup of your database.

Before downgrading the binaries, you must downgrade the feature compatibility version and remove any 4.0 features incompatible with 3.6 or earlier versions as generally outlined below. These steps are necessary only if featureCompatibilityVersion has ever been set to "4.0".


  1. Connect a mongo shell to the primary.

  2. Downgrade the featureCompatibilityVersion to "3.6".

    db.adminCommand({setFeatureCompatibilityVersion: "3.6"})

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

To ensure that all members of the replica set reflect the updated featureCompatibilityVersion, connect to each replica set member and check the featureCompatibilityVersion:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

All members should return a result that includes:

"featureCompatibilityVersion" : { "version" : "3.6" }

If any member returns a featureCompatibilityVersion that includes either a version value of "4.0" or a targetVersion field, wait for the member to reflect version "3.6" before proceeding.

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

Remove all persisted features that are incompatible with 4.0. For example, if you have defined any view definitions, document validators, and partial index filters that use 4.0 query features such as the aggregation convert operators, you must remove them.

If you have users with only SCRAM-SHA-256 credentials, you should create SCRAM-SHA-1 credentials for these users before downgrading. To update a user who only has SCRAM-SHA-256 credentials, run db.updateUser() with mechanisms set to SCRAM-SHA-1 only and the pwd set to the password:

mechanisms: [ "SCRAM-SHA-1" ],
pwd: <newpwd>


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


If you ran MongoDB 4.0 with authenticationMechanisms that included SCRAM-SHA-256, omit SCRAM-SHA-256 when restarting with the 3.6 binary.


Using either a package manager or a manual download, get the latest release in the 3.6 series. If using a package manager, add a new repository for the 3.6 binaries, then perform the actual downgrade process.

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


Downgrade each secondary member of the replica set, one at a time:

  1. Shut down the mongod. See Stop mongod Processes for instructions on safely terminating mongod processes.

  2. Replace the 4.0 binary with the 3.6 binary and restart.

  3. Wait for the member to recover to SECONDARY state before downgrading the next secondary. To check the member's state, use the rs.status() method in the mongo shell.


Use rs.stepDown() in the mongo shell to step down the primary and force the normal failover procedure.


rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.


When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 3.6 binary and start the new instance.


The MongoDB 3.6 deployment can use the BinData resume tokens returned from a change stream opened against the 4.0 deployment, but not the v0 or the v1 hex-encoded string resume tokens.

←  Downgrade 4.0 Standalone to 3.6Downgrade 4.0 Sharded Cluster to 3.6 →