MongoDB Documentation, Release 3.0.4 While the balancer is still disabled, upgrade the components of your sharded cluster in the following order: When this process is complete, you can now re-enable the balancer (page 717). Rolling Upgrade Limitation for 2.2.0 Deployments Running with auth Enabled MongoDB cannot support deployments that mix 2.2.0 and 2.4.0, or greater, components. MongoDB version 2.2.1 and later processes can exist in mixed deployments with 2.4-series processes. Therefore you cannot perform a rolling upgrade from MongoDB 2.2.0 to MongoDB 2.4.0. To upgrade a cluster with 2.2.0 components, use one of the following procedures. Upgrade from 2.3 to 2.4 If you used a mongod from the 2.3 or 2.4-rc (release candidate) series, you can safely transition these databases to 2.4.0 or later; however , if you created 2dsphere or text indexes using a mongod before v2.4-rc2, you will need to rebuild these indexes. For example: Downgrade MongoDB from 2.4 to Previous Versions For some cases the on-disk format of data files used by 2.4 and 2.2 mongod is compatible, and you can upgrade and downgrade if needed. However, several new features in 2.4 are incompatible with previous versions: Important: Collections sharded using hashed shard keys, should not use 2.2 mongod instances, which cannot correctly support cluster operations for these collections. If you completed the meta-data upgrade for a sharded cluster (page 893), you can safely downgrade to 2.2 MongoDB processes. Do not use 2.0 processes after completing the upgrade procedure. Note: In sharded clusters, once you have completed the meta-data upgrade procedure (page 893), you cannot use 2.0 mongod or mongos instances in the same cluster. If you complete the meta-data upgrade, you can safely downgrade components in any order. When upgrade again, always upgrade mongos instances before mongod instances. Do not create 2dsphere or text indexes in a cluster that has 2.2 components. 12.2. Previous Stable Releases 897 • 2dsphere indexes are incompatible with 2.2 and earlier mongod instances. • text indexes are incompatible with 2.2 and earlier mongod instances. • using a hashed index as a shard key are incompatible with 2.2 and earlier mongos instances. • hashed indexes are incompatible with 2.0 and earlier mongod instances. db.records.dropIndex( { loc: "2dsphere" } ) db.records.dropIndex( "records_text" ) db.records.ensureIndex( { loc: "2dsphere" } ) db.records.ensureIndex( { records: "text" } ) 1. Perform a rolling upgrade of all 2.2.0 processes to the latest 2.2-series release (e.g. 2.2.3) so that there are no processes in the deployment that predate 2.2.1. When there are no 2.2.0 processes in the deployment, perform a rolling upgrade to 2.4.0. 2. Stop all processes in the cluster. Upgrade all processes to a 2.4-series release of MongoDB, and start all pro- cesses at the same time. • Upgrade all mongos instances in the cluster, in any order. • Upgrade all 3 mongod config server instances, upgrading the first system in the mongos --configdb ar- gument last . • Upgrade each shard, one at a time, upgrading the mongod secondaries before running replSetStepDown and upgrading the primary of each shard.