Docs4dev
Docs
mongodb / v3.6 / reference / release-notes-3.2-downgrade.html

Downgrade MongoDB from 3.2

On this page

Before you attempt any downgrade, familiarize yourself with the content of this document, particularly the Downgrade Recommendations and Checklist and the procedure for downgrading sharded clusters.

Downgrade Recommendations and Checklist

When downgrading, consider the following:

Downgrade Path

To downgrade, use the latest version in the 3.0-series.

Preparedness

Procedures

Follow the downgrade procedures:

Prerequisites

Text Index Version Check

If you have version 3 text indexes (i.e. the default version for text indexes in MongoDB 3.2), drop the version 3 text indexes before downgrading MongoDB. After the downgrade, recreate the dropped text indexes.

To determine the version of your text indexes, run db.collection.getIndexes() to view index specifications. For text indexes, the method returns the version information in the field textIndexVersion. For example, the following shows that the text index on the quotes collection is version 3.

{
   "v" : 1,
   "key" : {
      "_fts" : "text",
      "_ftsx" : 1
   },
   "name" : "quote_text_translation.quote_text",
   "ns" : "test.quotes",
   "weights" : {
      "quote" : 1,
      "translation.quote" : 1
   },
   "default_language" : "english",
   "language_override" : "language",
   "textIndexVersion" : 3
}

2dsphere Index Version Check

If you have version 3 2dsphere indexes (i.e. the default version for 2dsphere indexes in MongoDB 3.2), drop the version 3 2dsphere indexes before downgrading MongoDB. After the downgrade, recreate the 2dsphere indexes.

To determine the version of your 2dsphere indexes, run db.collection.getIndexes() to view index specifications. For 2dsphere indexes, the method returns the version information in the field 2dsphereIndexVersion. For example, the following shows that the 2dsphere index on the locations collection is version 3.

{
   "v" : 1,
   "key" : {
      "geo" : "2dsphere"
   },
   "name" : "geo_2dsphere",
   "ns" : "test.locations",
   "sparse" : true,
   "2dsphereIndexVersion" : 3
}

Partial Indexes Check

Before downgrading MongoDB, drop any partial indexes.

Downgrade a Standalone mongod Instance

The following steps outline the procedure to downgrade a standalone mongod from version 3.2 to 3.0.

1

Download the latest 3.0 binaries.

For the downgrade, use the latest release in the 3.0 series.

2

Restart with the latest 3.0 mongod instance.

Important

If your mongod instance is using the WiredTiger storage engine, you must include the --storageEngine option (or storage.engine if using the configuration file) with the 3.0 binary.

Shut down your mongod instance. Replace the existing binary with the downloaded mongod binary and restart.

Downgrade a 3.2 Replica Set

The following steps outline a “rolling” downgrade process for the replica set. The “rolling” downgrade process minimizes downtime by downgrading the members individually while the other members are available:

1

Downgrade the protocolVersion.

Connect a mongo shell to the current primary and downgrade the replication protocol:

cfg = rs.conf();
cfg.protocolVersion=0;
rs.reconfig(cfg);
2

Downgrade secondary members of the replica set.

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 3.2 binary with the 3.0 binary and restart.

    Important

    If your mongod instance is using the WiredTiger storage engine, you must include the --storageEngine option (or storage.engine if using the configuration file) with the 3.0 binary.

  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.

3

Step down the primary.

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

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, shut down the previous primary and replace the mongod binary with the 3.0 binary and start the new instance.

Important

If your mongod instance is using the WiredTiger storage engine, you must include the --storageEngine option (or storage.engine if using the configuration file) with the 3.0 binary.

Replica set failover is not instant but will render the set unavailable to writes and interrupt reads until the failover process completes. Typically this takes 10 seconds or more. You may wish to plan the downgrade during a predetermined maintenance window.

Downgrade a 3.2 Sharded Cluster

Requirements

While the downgrade is in progress, you cannot make changes to the collection metadata. For example, during the downgrade, do not do any of the following: