On this page本页内容
Before you attempt any downgrade, familiarize yourself with the content of this document.
Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlier version. You can only downgrade to a 3.2.8 or later version.
Optional but Recommended. Create a backup of your database.
Before downgrading the binaries, you must downgrade the feature compatibility version and remove any 3.4 features incompatible with 3.2 or earlier versions as outlined below. These steps are necessary only if featureCompatibilityVersion
has ever been set to "3.4"
.
mongo
shell to the mongos
instance.featureCompatibilityVersion
to "3.2"
.db.adminCommand({setFeatureCompatibilityVersion: "3.2"})This command must perform writes to an internal system collection. If for any reason the command does not complete successfully, you can safely retry the command on the
mongos
instance as the operation is idempotent.If you have defined any views, drop the views before downgrading MongoDB 3.4 to 3.2.
mongo
shell to the mongos
instance.mongo
shell:db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos({type: "view"}).forEach(function(c){ print(mdb[c.name]); }); });In each database that contains views, drop the
system.views
collection to drop all views in that database.If running with access control, you must have privileges to drop the system.views
collection for the database. See Create a Role to Drop system.views
Collection across Databases.If you have defined any non-"simple" collation for a collection or an index, remove the collection or index before downgrading MongoDB 3.4 to 3.2.
mongo
shell to the mongos
instance.mongo
shell:db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos( { "options.collation": { $exists: true } } ).forEach(function(c){ print(mdb[c.name]); }); });You can migrate the content of the collection to a new collection without the collation specification (one way is via the aggregation pipeline stage
$out
).mongo
shell:db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos().forEach(function(c){ let currentCollection = mdb.getCollection(c.name); currentCollection.getIndexes().forEach(function(i){ if (i.collation){ printjson(i); } }); }); });Drop the indexes with a collation specification. After the downgrade, recreate the dropped indexes.
mongo
shell to the mongos
instance.db.collection.validate(true)
against the collections which may contain decimal data.db.collection.validate(true)
reports on decimal data only when featureCompatibilityVersion
is "3.2"
.If you have v: 2
indexes (i.e. the default version for indexes created in MongoDB 3.4 if featureCompatibilityVersion: "3.4"
), reindex the collection
to recreate all indexes on the collection as v: 1
before downgrading MongoDB.
You must perform this operation on both the shards and the config servers:
mongo
shell to the mongos
instance.v: 2
, you can run the following in the mongo
shell:db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos().forEach(function(c){ let currentCollection = mdb.getCollection(c.name); currentCollection.getIndexes().forEach(function(i){ if (i.v === 2){ printjson(i); } }); }); });
If a shard is a replica set, repeat this procedure on each member of the shard as the reindex operation does not propagate to the secondaries.
If connecting a mongo
shell to a secondary member, use db.getMongo()
to allow reads from secondaries.
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:
sh.enableSharding()
sh.shardCollection()
sh.addShard()
db.createCollection()
db.collection.drop()
db.dropDatabase()
Using either a package manager or a manual download, get the latest release in the 3.2 series. If using a package manager, add a new repository for the 3.2 binaries, then perform the actual downgrade process.
Once upgraded to 3.4, you cannot downgrade to a 3.2.7 or earlier version. You can only downgrade to a 3.2.8 or later version.
Turn off the balancer as described in Disable the Balancer.
Downgrade the shards one at a time. If the shards are replica sets, for each shard:
Downgrade the secondary members of the replica set one at a time:
mongod
instance and replace the 3.4
binary with the 3.2 binary.Start the 3.2 binary with the --shardsvr
and --port
command line options.
mongod --shardsvr --port <port> --dbpath <path>
Of if using a configuration file, update the file to include sharding.clusterRole: shardsvr
and net.port
and start:
sharding: clusterRole: shardsvr net: port: <port> storage: dbpath: <path>
Include any other configuration as appropriate for your deployment.
Wait for the member to recover to SECONDARY
state before downgrading the next secondary member. To check the member's state, you can issue rs.status()
in the mongo
shell.
Repeat for each secondary member.
Step down the replica set primary.
Connect a mongo
shell to the primary and use rs.stepDown()
to step down the primary and force an election of a new primary:
rs.stepDown()
When rs.status()
shows that the primary has stepped down and another member has assumed PRIMARY
state, downgrade the stepped-down primary:
mongod
binary with the 3.2 binary.Start the 3.2 binary with the --shardsvr
and --port
command line options.
mongod --shardsvr --port <port> --dbpath <path>
Or if using a configuration file, update the file to specify sharding.clusterRole: shardsvr
and net.port
and start the 3.2 binary:
sharding: clusterRole: shardsvr net: port: <port> storage: dbpath: <path>
Include any other configuration as appropriate for your deployment.
If the config servers are replica sets:
Downgrade the secondary members of the replica set one at a time:
mongod
instance and replace the 3.4 binary with the 3.2 binary.Start the 3.2 binary with both the --configsvr
and --port
options:
mongod --configsvr --port <port> --dbpath <path>
If using a configuration file, update the file to specify sharding.clusterRole: configsvr
and net.port
and start the 3.4 binary:
sharding: clusterRole: configsvr net: port: <port> storage: dbpath: <path>
Include any other configuration as appropriate for your deployment.
Wait for the member to recover to SECONDARY
state before downgrading the next secondary member. To check the member's state, issue rs.status()
in the mongo
shell.
Repeat for each secondary member.
Step down the replica set primary.
Connect a mongo
shell to the primary and use rs.stepDown()
to step down the primary and force an election of a new primary:
rs.stepDown()
rs.status()
shows that the primary has stepped down and another member has assumed PRIMARY
state, shut down the stepped-down primary and replace the mongod
binary with the 3.2 binary.Start the 3.2 binary with both the --configsvr
and --port
options:
mongod --configsvr --port <port> --dbpath <path>
If using a configuration file, update the file to specify sharding.clusterRole: configsvr
and net.port
and start the 3.4 binary:
sharding: clusterRole: configsvr net: port: <port> storage: dbpath: <path>
Include any other configuration as appropriate for your deployment.
Once the downgrade of sharded cluster components is complete, re-enable the balancer.