MongoDB Sharded Cluster Upgrade from 2.4 to 3.2 version

mongodb

I need to upgrade MongoDB Sharded Cluster from 2.4 to 3.2 .

Based on documentation, I need to upgrade from 2.4->2..6->3.0->3.2

So it looks like lots of upgrade from 2.4 to go to 3.2 version.

We have 3 Shards with 3 replica sets.

Each Shard also runs 1 config server and router service

Upgrade Document :
https://docs.mongodb.com/manual/release-notes/2.6-upgrade/#upgrade-a-sharded-cluster-to-2-6.

Question :
1. Should all cluster should be upgraded to 2.4 to 2.6 first and then follow same process from 2.6 to 3.0 and 3.0 to 3.2 ?

  1. Upgrade Sharded Clusters:
    Upgrade the cluster’s meta data

    It even did not mention that I need to shutdown existing config DB process. Do I need to shutdown 1 config server on shard and follow upgrade process ? Do I need to upgrade all config servers like this or since Config Server data is synched automatically , I need to upgrade only one config server and then replace binary for 2.6 on other servers.

Please clarify following points :
Upgrade Sharded Clusters

Optional but Recommended. As a precaution, take a backup of the config database before upgrading the sharded cluster.

1.
Disable the Balancer.
Turn off the balancer in the sharded cluster, as described in Disable the Balancer.

This looks good.

2.
Upgrade the cluster’s meta data.
Start a single 2.6 mongos instance with the configDB pointing to the cluster’s config servers and with the –upgrade option.

It says Start a single 2.6 mongos. It is not clear to me, at this point should my whole existing cluster should be down or I need to just just down one config server and do upgrade. It even did not mention, I need to stop/shutdown config database on one server. It just says "Start with 2.6 binary with upgrade option" so it is confusing to me. Can someone clarify ?

To run a mongos with the –upgrade option, you can upgrade an existing mongos instance to 2.6, or if you need to avoid reconfiguring a production mongos instance, you can use a new 2.6 mongos that can reach all the config servers.

mongos –configdb –upgrade
You can include the –logpath option to output the log messages to a file instead of the standard output. Also include any other options required to start mongos instances in your cluster, such as –sslOnNormalPorts or –sslPEMKeyFile.

The mongos will exit upon completion of the –upgrade process.

The upgrade will prevent any chunk moves or splits from occurring during the upgrade process. If the data files have many sharded collections or if failed processes hold stale locks, acquiring the locks for all collections can take seconds or minutes. Watch the log for progress updates.

Good with instructions …

3.
Ensure mongos –upgrade process completes successfully.
The mongos will exit upon completion of the meta data upgrade process. If successful, the process will log the following messages:

upgrade of config server to v5 successful
Config database is at version v5
After a successful upgrade, restart the mongos instance. If mongos fails to start, check the log for more information.

If the mongos instance loses its connection to the config servers during the upgrade or if the upgrade is otherwise unsuccessful, you may always safely retry the upgrade.

Good with instructions …

4.
Upgrade the remaining mongos instances to v2.6.
Upgrade and restart without the –upgrade option the other mongos instances in the sharded cluster. After upgrading all the mongos, see Complete Sharded Cluster Upgrade for information on upgrading the other cluster components.

Upgrade and restart without the –upgrade option so there is no need to use –upgrade option. I am not not sure why step is called Upgrade and restart, it should be simple restart. Am I missing any thing here ?
When we upgrade our first config db with upgrade option, other config db should automatically sync with first one, the only thing which I need to do is to start with 2.6 binary. Is my understanding correct ?

Best Answer

  1. Yes. Period. No "Ok, but..."
  2. You should make a backup. Start now, continue reading later. It is presumably going to take a while.
  3. Config servers in 2.4, 2.6 and 3.0 do *not* form a replica set. Those were basically 3 standalone instances.
  4. Read and understand the migration guide to 2.6 for sharded clusters. Rinse, repeat.
  5. Read and understand the migration guide to 3.0 for sharded clusters. Rinse, repeat.
  6. Read and understand the migration guide to 3.2 for sharded clusters Rinse, repeat.
  7. Read the guide Upgrade Config Servers to Replica Set. Rinse, repeat.
  8. Wait until your backup is done.
  9. Upgrade to 2.6 according to guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
  10. Upgrade to 3.0 according to the guide mentioned above. Migrate to WiredTiger in the process, unless you have very strange requirements. That is: shutdown data secondary data bearing node, delete its datadir, adjust config to utilize WT, resync, proceed. Have primary step down Before shut down. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
  11. Upgrade to 3.2 according to the guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
  12. Convert your config servers to a replica set according to the guide mentioned above. Make sure (aka "test thoroughly") your cluster works as expected. Continue at the next appropriate maintenance window.
  13. Take a few notes: "Good resolution 1: read release notes and docs of my chosen persistence technology. Good resolution 2: I will only ask questions to my peers after thoroughly researching the topic myself."
Related Question