MongoDB Documentation, Release 3.0.4 3. Ensure there are no version 2.0 mongod or mongos processes still active in the sharded cluster. The automated upgrade process checks for 2.0 processes, but network availability can prevent a definitive check. Wait 5 minutes after stopping or upgrading version 2.0 mongos processes to confirm that none are still active. 4. Start a single 2.4 mongos process with configDB pointing to the sharded cluster’s config servers (page 670) and with the --upgrade option. The upgrade process happens before the process becomes a daemon (i.e. before --fork .) 5. When the mongos process starts successfully, the upgrade is complete. If the mongos process fails to start, check the log for more information. 6. Upgrade and restart other mongos processes in the sharded cluster, without the --upgrade option. 7. Re-enable the balancer (page 717). You can now perform operations that modify cluster meta-data. Once you have upgraded, do not introduce version 2.0 MongoDB processes into the sharded cluster. This can rein- troduce old meta-data formats into the config servers. The meta-data change made by this upgrade process will help prevent errors caused by cross-version incompatibilities in future versions of MongoDB. See Upgrade Sharded Cluster Components (page 896) for more information. It is always more safe to wait for the mongos to verify that the lock is inactive, if you have any doubts about the activity of another upgrade operation. In addition to the configUpgrade , the mongos may need to wait for specific collection locks. Do not force the specific collection locks. db.getMongo().getCollection("config.locks").update({ _id : "configUpgrade" }, { $set : If the process specified in the process field of this document is verifiably offline, run the following operation to force the lock. db.getMongo().getCollection("config.locks").findOne({ _id : "configUpgrade" }) mongo <mongos.example.net> If the mongos logs show the upgrade waiting for the upgrade lock, a previous upgrade process may still be active or may have ended abnormally. After 15 minutes of no remote activity mongos will force the upgrade lock. If you can verify that there are no running upgrade processes, you may connect to a 2.2 mongos process and force the lock manually: If the mongos terminates or loses its connection to the config servers during the upgrade, you may always safely retry the upgrade. However, if the upgrade failed during the short critical section, the mongos will exit and report that the up- grade will require manual intervention. To continue the upgrade process, you must follow the Resync after an Interruption of the Critical Section (page 896) procedure. Optional You can upgrade an existing mongos instance to 2.4 or you can start a new mongos instance that can reach all config servers if you need to avoid reconfiguring a production mongos . Start the mongos with a command that resembles the following: mongos --configdb <config servers> --upgrade Without the --upgrade option 2.4 mongos processes will fail to start until the upgrade process is complete. The upgrade will prevent any chunk moves or splits from occurring during the upgrade process. If there are very many sharded collections or there are stale locks held by other failed processes, acquiring the locks for all collections can take seconds or minutes. See the log for progress updates. 895 12.2. Previous Stable Releases