Navigation

Downgrade 3.6 Replica Set to 3.4

On this page

Before you attempt any downgrade, familiarize yourself with the content of 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 feature compatibility version and remove any 3.6 features incompatible with 3.4 or earlier versions as generally outlined below. These steps are necessary only if featureCompatibilityVersion has ever been set to "3.6".

1. Downgrade Feature Compatibility Version

Tip

  1. Connect a mongo shell to the primary.

  2. Downgrade the featureCompatibilityVersion to "3.4".

    copy 
    db.adminCommand({setFeatureCompatibilityVersion: "3.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 primary.

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

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

All members should return a result that includes:

copy 
"featureCompatibilityVersion" : { "version" : "3.4" }

If any member returns a featureCompatibilityVersion that includes either 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 featureCompatibilityVersion value, see View FeatureCompatibilityVersion.

2. Remove Backwards Incompatible Persisted Features

Remove all persisted features that are incompatible with 3.4. For example, if you have defined any any view definitions, document validators, and partial index filters 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 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.

1

Download the latest 3.4 binaries.

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

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

2

Downgrade secondary members of the replica set.

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

  1. Perform a clean shut down of the mongod process.

    Note

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

    Forcibly terminating the mongod process may cause inaccurate results for db.collection.count() and db.stats() as well as lengthen startup time the next time that the mongod process is restarted.

    This applies whether you attempt to terminate the mongod process from the command line via kill or similar, or whether you use your platform’s initialization system to issue a stop command, like sudo systemctl stop mongod or sudo service mongod stop.

  2. Replace the 3.6 binary with the 3.4 binary.

  3. Start the 3.4 mongod process.

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

3

Step down the primary.

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

copy 
rs.stepDown()

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

4

Replace and restart former primary mongod.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, perform a clean shut down of the previous primary and replace the mongod binary with the 3.4 binary and start the new process.

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.