发布于 2015-09-14 15:08:49 | 125 次阅读 | 评论: 0 | 来源: 网络整理
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.
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.
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 downtime.
The upgrade to MongoDB 2.4 adds epochs to the metadata 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.
While the upgrade is in progress, you cannot make changes to the collection metadata. For example, you cannot perform operations that add shards, drop databases, or drop collections, or modify the metadata in any other way.
警告
Once you upgrade to 2.4 and complete the upgrade procedure do not use 2.0 mongod and mongos processes in your cluster. 2.0 process may re-introduce old metadata formats into cluster metadata.
Do not perform operations that modify metadata while performing this procedure.
Turn off the balancer in the sharded cluster, as described in Disable the Balancer.
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.
Start a single 2.4 mongos process with configdb pointing to the sharded cluster’s config servers and with the --upgrade option. 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 server> --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, acquiring the locks for all collections may take seconds or minutes. See the log for progress updates.
When the mongos process starts successfully, the upgrade is complete. If the mongos process fails to start, check the log for more information.
If a network interruption occurred and prevented changes, see Resync after a Network Interruption.
Re-enable the balancer. You can now perform operations that modify cluster metadata.
Upgrade and restart other mongos processes in the sharded cluster, without the --upgrade option.
Once you have upgraded, do not introduce version 2.0 MongoDB processes into the sharded cluster. This can reintroduce old metadata formats into the config servers. The metadata change made by this upgrade process will help prevent errors caused by cross-version incompatibilities in future versions of MongoDB.
During the short critical section of the upgrade that applies changes to the metadata, 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 must be re-synced, and there may be problems starting new mongos processes. The sharded cluster will remain accessible, but avoid all cluster metadata changes until you resync the config servers. Operations that change metadata include: adding shards, dropping databases, and dropping collections.
To resync the config servers:
Turn off the balancer in the sharded cluster and stop all metadata operations. If you are in the middle of an upgrade process (Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4), you have already disabled the balancer. .
Shut down two of the three config servers, preferably the last two listed in the configdb string. For example, 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 metadata.
mongodump the data files of the active config server (configA).
Move the data files of the deactivated config servers (configB and configC) to a backup location.
Create new, empty data directories.
Restart the disabled config servers with --dbpath pointing to the now-empty data directory and --port pointing to an alternate port (e.g. 27020).
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.
Restart the restored config servers on the old port, resetting the port back to the old settings (configB:27019 and configC:27019).
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 setprimaries.
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:
mongo <2.2 mongos port>
Then, use the following operation to reset the upgrade process:
db.getMongo().getCollection("config.version").update({ _id : 1 }, { $unset : { upgradeState : 1 } })
Finally retry the upgrade process, as in Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4.