MongoDB Documentation, Release 3.0.4 Resync after an Interruption of the Critical Section During the short critical section of the upgrade that applies changes to the meta-data, it is unlikely but possible that a network interruption can prevent all three config servers from verifying or modifying data. If this occurs, the config servers (page 670) must be re-synced, and there may be problems starting new mongos processes. The sharded cluster will remain accessible, but avoid all cluster meta- data changes until you resync the config servers. Operations that change meta-data include: adding shards, dropping databases, and dropping collections. Note: Only perform the following procedure if something (e.g. network, power, etc.) interrupts the upgrade process during the short critical section of the upgrade. Remember, you may always safely attempt the meta data upgrade procedure (page 894). To resync the config servers: Then, use the following operation to reset the upgrade process: Upgrade Sharded Cluster Components After you have successfully completed the meta-data upgrade process described in Meta-data Upgrade Procedure (page 894), and the 2.4 mongos instance starts, you can upgrade the other processes in your MongoDB deployment. 896 Chapter 12. Release Notes 1. Turn off the balancer (page 684) in the sharded cluster and stop all meta-data operations. If you are in the middle of an upgrade process ( Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4 (page 893)), you have already disabled the balancer. 2. Shut down two of the three config servers, preferably the last two listed in the configDB string. For ex- ample, if your configDB string is configA:27019,configB:27019,configC:27019 , shut down configB and configC . Shutting down the last two config servers ensures that most mongos instances will have uninterrupted access to cluster meta-data. 3. mongodump the data files of the active config server ( configA ). 4. Move the data files of the deactivated config servers ( configB and configC ) to a backup location. 5. Create new, empty data directories . 6. Restart the disabled config servers with --dbpath pointing to the now-empty data directory and --port pointing to an alternate port (e.g. 27020 ). 7. Use mongorestore to repopulate the data files on the disabled documents from the active config server ( configA ) to the restarted config servers on the new port ( configB:27020,configC:27020 ). These config servers are now re-synced. 8. Restart the restored config servers on the old port, resetting the port back to the old settings ( configB:27019 and configC:27019 ). 9. In some cases connection pooling may cause spurious failures, as the mongos disables old connections only after attempted use. 2.4 fixes this problem, but to avoid this issue in version 2.2, you can restart all mongos instances (one-by-one, to avoid downtime) and use the rs.stepDown() method before restarting each of the shard replica set primaries . 10. The sharded cluster is now fully resynced; however before you attempt the upgrade process again, you must manually reset the upgrade state using a version 2.2 mongos . Begin by connecting to the 2.2 mongos with the mongo shell: 11. Finally retry the upgrade process, as in Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4 (page 893). mongo <mongos.example.net> db.getMongo().getCollection("config.version").update({ _id : 1 }, { $unset : { upgradeState