Downgrade 4.0 Replica Set to 3.6

Downgrade 4.0 Replica Set to 3.6

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

Downgrade Path

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

Change Stream Consideration

MongoDB 4.0 introduces new hex-encoded string change streamresume tokens:

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

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	“4.0”	Hex-encoded string (`v0`)
MongoDB 4.0.6 and earlier	“3.6”	BinData
MongoDB 3.6	“3.6”	BinData

When downgrading from MongoDB 4.0.7 or greater, clients cannot usethe resume tokens returned from the 4.0.7+ deployment. To resume achange stream, clients will need to use a pre-4.0.7 upgrade resumetoken (if available). Otherwise, clients will need to start a new change stream.
When downgrading from MongoDB 4.0.6 or earlier, clients can useBinData resume tokens returned from the 4.0 deployment, but not thev0 tokens.

Create Backup

Optional but Recommended. Create a backup of your database.

Prerequisites

Before downgrading the binaries, you must downgrade the featurecompatibility version and remove any 4.0 featuresincompatible with 3.6 or earlierversions as generally outlined below. These steps are necessary only iffeatureCompatibilityVersion has ever been set to "4.0".

1. Downgrade Feature Compatibility Version

Tip

Ensure that no initial sync is in progress. RunningsetFeatureCompatibilityVersion command while aninitial sync is in progress will cause the initial sync to restart.
Ensure that no replica set member is in ROLLBACK orRECOVERING state.

Connect a mongo shell to the primary.
Downgrade the featureCompatibilityVersion to "3.6".

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

The setFeatureCompatibilityVersion command performs writesto an internal system collection and is idempotent. If for any reasonthe command does not complete successfully, retry the command on theprimary.

To ensure that all members of the replica set reflect the updatedfeatureCompatibilityVersion, connect to each replica set member andcheck 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 includeseither 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 featureCompatibilityVersionvalue, see View FeatureCompatibilityVersion.

2. Remove Backwards Incompatible Persisted Features

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

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

db.updateUser(
   "reportUser256",
   {
     mechanisms: [ "SCRAM-SHA-1" ],
     pwd: <newpwd>
   }
)

Procedure

Warning

Before proceeding with the downgrade procedure, ensure that allreplica set members, including delayed replica set members, reflectthe prerequisite changes. That is, check thefeatureCompatibilityVersion and the removal of incompatiblefeatures for each node before downgrading.

Note

If you ran MongoDB 4.0 with authenticationMechanismsthat included SCRAM-SHA-256, omit SCRAM-SHA-256 whenrestarting with the 3.6 binary.

Download the latest 3.6 binaries.

Using either a package manager or a manual download, get the latestrelease in the 3.6 series. If using a package manager, add a newrepository for the 3.6 binaries, then perform the actual downgradeprocess.

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

Downgrade secondary members of the replica set.

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

Shut down the mongod. See Stop mongod Processes for instructions on safely terminating mongod processes.
Replace the 4.0 binary with the 3.6 binary and restart.
Wait for the member to recover to SECONDARY statebefore downgrading the next secondary. To check the member’s state,use the rs.status() method in the mongo shell.

Step down the primary.

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

rs.stepDown()

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

Replace and restart former primary mongod.

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

Note

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