Upgrade MongoDB to 3.2

Before you attempt any upgrade, please familiarize yourself with thecontent of this document.

If you need guidance on upgrading to 3.2, MongoDB offers 3.2 upgrade services to help ensure a smooth transition without interruption to yourMongoDB application.

Upgrade Recommendations and Checklists

When upgrading, consider the following:

Upgrade Requirements

To upgrade an existing MongoDB deployment to 3.2, you must be running a3.0-series release.

To upgrade from a 2.6-series release, you must upgrade to the latest3.0-series release before upgrading to 3.2. For the procedure toupgrade from the 2.6-series to a 3.0-series release, see Upgradeto 3.0.

Preparedness

Before beginning your upgrade, see the Compatibility Changes inMongoDB 3.2 document to ensure thatyour applications and deployments are compatible with MongoDB 3.2.Resolve the incompatibilities in your deployment before starting theupgrade.

Before upgrading MongoDB, always test your application in a stagingenvironment before deploying the upgrade to your productionenvironment.

Upgrade Standalone mongod Instance to MongoDB 3.2

The following steps outline the procedure to upgrade a standalonemongod from version 3.0 to 3.2. To upgrade from version2.6 to 3.2, upgrade to the latest3.0-series releasefirst, and then use the following procedure to upgrade from 3.0 to 3.2.

Upgrade with Package Manager

If you installed MongoDB from the MongoDB apt, yum, dnf, orzypper repositories, you should upgrade to 3.2 using your packagemanager. Follow the appropriate installation instructions for your Linux system. This willinvolve adding a repository for the new release, then performing theactual upgrade.

Manual Upgrade

Otherwise, you can manually upgrade MongoDB:

Download 3.2 binaries.

Download binaries of the latest release in the 3.2 series from theMongoDB Download Page. See Install MongoDB for moreinformation.

Replace with 3.2 binaries

Shut down your mongod instance. Replace the existingbinary with the 3.2 mongod binary and restartmongod.

Note

MongoDB 3.2 generates core dumps on some mongodfailures. For production environments, you may prefer to turn off coredumps for the operating system, if not already.

Upgrade a Replica Set to 3.2

Prerequisites

All replica set members must be running version 3.0 before you canupgrade them to version 3.2. To upgrade a replica set from an earlierMongoDB version, upgrade all members of the replica set to the latest3.0-series releasefirst, and then follow the procedureto upgrade from MongoDB 3.0 to 3.2.

Upgrade Binaries

You can upgrade from MongoDB 3.0 to 3.2 using a “rolling” upgrade tominimize downtime by upgrading the members individually while the othermembers are available:

Avoid reconfiguring replica sets that contain members of differentMongoDB versions as validation rules may differ across MongoDB versions.

Upgrade secondary members of the replica set.

Upgrade the secondarymembers of the replica set one at a time:

• Shut down the mongod instance and replace the 3.0binary with the 3.2 binary.
• Restart the member and wait for the member to recover toSECONDARY state before upgrading the next secondary member.To check the member’s state, issue rs.status() in themongo shell.

Step down the replica set primary.

Connect a mongo shell to the primary and users.stepDown() to step down the primary and force anelection of a new primary:

Upgrade the primary.

When rs.status()shows that the primary has stepped down and another memberhas assumed PRIMARY state, upgrade the stepped-down primary:

• Shut down the stepped-down primary and replace themongod binary with the 3.2 binary.
• Restart.

Replica set failover is not instant and will render the setunavailable to accept writes until the failover processcompletes. This may take 30 seconds or more: schedule theupgrade procedure during a scheduled maintenance window.

Note

MongoDB 3.2 generates core dumps on some mongodfailures. For production environments, you may prefer to turn off coredumps for the operating system, if not already.

Upgrade a Sharded Cluster to 3.2

Prerequisites

• • Version 3.0 or Greater
  • To upgrade a sharded cluster to 3.2, all members of thecluster must be at least version 3.0. The upgrade process checksall components of the cluster and will produce warnings if anycomponent is running version earlier than 3.0.
• • Stop Metadata Changes during the Upgrade

  • During the upgrade, ensure that clients do not make changes to thecollection metadata. For example, during the upgrade, do notperform any of the following operations:

    • sh.enableSharding()
    • sh.shardCollection()
    • sh.addShard()
    • db.createCollection()
    • db.collection.drop()
    • db.dropDatabase()
    • any operation that creates a database
    • any other operation that modifies the cluster metadata in any way.See the Sharding Reference for a complete list of shardingcommands. Not all commands on the Sharding Reference pagemodify the cluster metadata.

• Disable the balancer

• • Back up the config Database
  • Optional but Recommended. As a precaution, take a backup of theconfig database before upgrading the sharded cluster.

Upgrade Binaries

Disable the Balancer.

Disable the balancer as described inDisable the Balancer.

Upgrade the shards.

Upgrade the shards one at a time. If the shards are replica sets,for each shard:

• Upgrade the secondarymembers of the replica set one at a time:

  • Shut down the mongod instance and replace the 3.0binary with the 3.2 binary.
  • Restart the member and wait for the member to recover toSECONDARY state before upgrading the next secondary member.To check the member’s state, issue rs.status() in themongo shell.
• Step down the replica set primary.

Connect a mongo shell to the primary and users.stepDown() to step down the primary and force anelection of a new primary:

rs.stepDown()

• When rs.status()shows that the primary has stepped down and another memberhas assumed PRIMARY state, upgrade the stepped-down primary:

  • Shut down the stepped-down primary and replace themongod binary with the 3.2 binary.
  • Restart.

Upgrade the config servers.

Upgrade the config servers one at a time in reverse order of theconfigDB or —configdb setting for themongos. That is, if the mongos has thefollowing —configdb listing:

mongos --configdb confserver1:port1,confserver2:port2,confserver3:port2

Upgrade first confserver3, then confserver2, and lastlyconfserver1.

Starting with the last config server listed in theconfigDB setting:

• Stop the config server and replace 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, specifysharding.clusterRole: configsvrand net.port in the file:

sharding:
   clusterRole: configsvr
net:
   port: <port>
storage:
   dbpath: <path>

Repeat for the config server listed second in theconfigDB setting, and finally the config serverlisted first in the configDB setting.

Upgrade the mongos instances.

Replace each mongos instance with the 3.2 binary andrestart.

mongos --configdb <cfgsvr1:port1>,<cfgsvr2:port2>,<cfgsvr3:port3>

Re-enable the balancer.

Re-enable the balancer as described inEnable the Balancer.

Note

MongoDB 3.2 generates core dumps on some mongod failures.For production environments, you may prefer to turn off core dumpsfor the operating system, if not already.

Once the sharded cluster binaries have been upgraded to 3.2, existingconfig servers will continue to run as mirrored mongodinstances. For instructions on upgrading existing config servers to areplica set, see Upgrade Config Servers to Replica Set (requires MongoDBversion 3.2.4 or later versions).