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
- Ensure that no initial sync is in progress. Running
setFeatureCompatibilityVersion
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.4"
.
- 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
:
- db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
All members should return a result that includes:
- "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 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 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:
- Perform a clean shut downof the
mongod
process.
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 thers.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.
- 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.