Downgrade 3.6 Replica Set to 3.4

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

Downgrade Path

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

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 3.6 featuresincompatible with 3.4 or earlierversions as generally outlined below. These steps are necessary only iffeatureCompatibilityVersion has ever been set to "3.6".

1. Downgrade Feature Compatibility Version

Tip

  • Connect a mongo shell to the primary.

  • Downgrade the featureCompatibilityVersion to "3.4".

  1. db.adminCommand({setFeatureCompatibilityVersion: "3.4"})

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:

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

All members should return a result that includes:

  1. "featureCompatibilityVersion" : { "version" : "3.4" }

If any member returns a featureCompatibilityVersion that includeseither a version value of "3.6" or a targetVersion field,wait for the member to reflect version "3.4" 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 3.4. For example, if you have definedany any view definitions, document validators, and partial indexfilters that use 3.6 query features such as $jsonSchema or$expr, you must remove them.

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.

Download the latest 3.4 binaries.

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

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

Downgrade secondary members of the replica set.

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

Note

If you do not perform a clean shut down, errors may result thatprevent the mongod process from starting.

Forcibly terminating the mongod process may causeinaccurate results for db.collection.count() anddb.stats() as well as lengthen startup time the next timethat the mongod process is restarted.

Invoking sudo service mongod stop does not guarantee aclean shutdown. This service script forceably stops themongod process if it takes longer than fiveminutes to shut down.

  • Replace the 3.6 binary with the 3.4 binary.

  • Start the 3.4 mongod process.

  • Wait for the member to recover to SECONDARY statebefore downgrading the next secondary. To check the member’sstate, use the rs.status() method in themongo shell.

Step down the primary.

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

  1. 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,perform a clean shut down of theprevious primary and replace the mongod binary withthe 3.4 binary and start the new process.