MongoDB Documentation, Release 3.0.4 Upgrade a Replica Set to 2.6 The following steps outline the procedure to upgrade a replica set from MongoDB 2.4 to MongoDB 2.6. To upgrade from MongoDB 2.2 to 2.6, upgrade all members of the replica set to version 2.4 (page 892) first , and then follow the procedure to upgrade from MongoDB 2.4 to 2.6. You can upgrade from MongoDB 2.4 to 2.6 using a “rolling” upgrade to minimize downtime by upgrading the mem- bers individually while the other members are available: Step 1: Upgrade secondary members of the replica set. Upgrade the secondary members of the set one at a time by shutting down the mongod and replacing the 2.4 binary with the 2.6 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. Step 2: Step down the replica set primary. Use rs.stepDown() in the mongo shell to step down the primary and force the set to failover (page 580). rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly. Step 3: Upgrade the primary. When rs.status() shows that the primary has stepped down and another mem- ber has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 2.6 binary and start the new instance. Replica set failover is not instant but will render the set unavailable accept writes until the failover process completes. Typically this takes 30 seconds or more: schedule the upgrade procedure during a scheduled maintenance window. Upgrade a Sharded Cluster to 2.6 Only upgrade sharded clusters to 2.6 if all members of the cluster are currently running instances of 2.4. The only supported upgrade path for sharded clusters running 2.2 is via 2.4. The upgrade process checks all components of the cluster and will produce warnings if any component is running version 2.2. Considerations The upgrade process does not require any downtime. However, while you upgrade the sharded cluster, ensure that clients do not make changes to the collection meta-data. For example, during the upgrade, do not do any of the following: Upgrade Sharded Clusters Optional but Recommended. As a precaution, take a backup of the config database before upgrading the sharded cluster. Step 1: Disable the Balancer. Turn off the balancer (page 684) in the sharded cluster, as described in Disable the Balancer (page 717). • 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 Sharding Reference (page 736) for a com- plete list of sharding commands. Note, however, that not all commands on the Sharding Reference (page 736) page modifies the cluster meta-data. Chapter 12. Release Notes 868