MongoDB Documentation, Release 3.0.4 1. Upgrade the secondary members of the set one at a time by shutting down the mongod and replacing the 2.2 binary with the 2.4 binary. After upgrading a mongod instance, wait for the member to recover to SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell. 2. Use the mongo shell method rs.stepDown() to step down the primary to allow the normal failover (page 580) procedure. rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly. Once the primary has stepped down and another member has assumed PRIMARY state, as observed in the output of rs.status() , shut down the previous primary and replace mongod binary with the 2.4 binary and start the new process. Note: Replica set failover is not instant but will render the set unavailable to read or accept writes until the failover process completes. Typically this takes 10 seconds or more. You may wish to plan the upgrade during a predefined maintenance window. Important: Only upgrade sharded clusters to 2.4 if all members of the cluster are currently running instances of 2.2. The only supported upgrade path for sharded clusters running 2.0 is via 2.2. Overview Upgrading a sharded cluster from MongoDB version 2.2 to 2.4 (or 2.3) requires that you run a 2.4 mongos with the --upgrade option, described in this procedure. The upgrade process does not require down- time. The upgrade to MongoDB 2.4 adds epochs to the meta-data for all collections and chunks in the existing cluster. MongoDB 2.2 processes are capable of handling epochs, even though 2.2 did not require them. This procedure applies only to upgrades from version 2.2. Earlier versions of MongoDB do not correctly handle epochs. See Cluster Meta- data Upgrade (page 893) for more information. After completing the meta-data upgrade you can fully upgrade the components of the cluster. With the balancer disabled: See Upgrade Sharded Cluster Components (page 896) for more information. Considerations Beware of the following properties of the cluster upgrade process: Additionally, ensure that all indexes in the config database (page 737) are {v:1} indexes. If a critical index is a {v:0} index, chunk splits can fail due to known issues with the {v:0} format. {v:0} indexes are present on clusters created with MongoDB 2.0 or earlier. The duration of the metadata upgrade depends on the network latency between the node performing the upgrade and the three config servers. Ensure low latency between the upgrade process and the config servers. 12.2. Previous Stable Releases 893 • Before you start the upgrade, ensure that the amount of free space on the filesystem for the config database (page 737) is at least 4 to 5 times the amount of space currently used by the config database (page 737) data files. • Upgrade all mongos instances in the cluster. • Upgrade all 3 mongod config server instances. • Upgrade the mongod instances for each shard, one at a time. Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4 Cluster Meta-data Upgrade