Upgrading Mongodb when config instances use the same binary as data instances

Question

I'm about to upgrade a sharded MongoDB environment from 2.0.7 to 2.2.9, ultimately I want to upgrade to 2.4.9 but apparently I need to do this via 2.2. The release notes for 2.2 state that the config servers should have their binaries upgraded first, then the shards. I currently have the config instances using the same Mongo binary as the data instances. Essentially there are three shards each with three replicas, and one replica out of each shard also functions as a config instance. Since they share a binary I can't upgrade the config instances independent of some of the data instances.

1. Would upgrading some data instances before all of the config instances cause any problems, assuming I've disabled the balancer?
2. Should I change the config instances to use a different copy of the binary? If so, what's the best way to go about this for an existing production setup running on Ubuntu 12?
3. Should I remove the three data instances from the replica sets, upgrade the config instances, then start the data instances up again, effectively updating them as well, but in the right order? This last option is a bit hairy as some are primaries, so I would have to step them down before removing them from the replica sets. This last option would also occur again when I have to do the next upgrade, so I'm not really a fan.

Answer 1

I resolved this issue by:

1. Adding the binaries for the new version to a new folder.
2. Restarting the config instances using the new binaries so that the data instances could continue to run with the old binaries
3. Once all of the config servers were upgraded I created yet another folder in which to put the same new binaries from step 1
4. I then restarted the data instances using these new binaries
5. Now the config instances and data instances on the same server are using the new binaries but in different folders so that it will be easier to upgrade them for the next release

Note that there are other steps involved with the upgrade, and these are specified in the release notes which you should always follow. However, this is how I dealt with the shared binary problem which is not directly addressed in the release notes.

A lot of the tutorials seem to use a single binary for data and config instances on a single server but this is problematic when it's time to upgrade. I'd suggest always using separate binaries for your config and data instances.

Answer 2

Even if the config server and data server share the same binary, you can upgrade them one by one. The first step is upgrade the mongodb package. The second step is to shut down the config server, restart it using the new binary. The third step is to shut down the data server, restart it using the new binary.

Answer 3

I invite you to look to the release notes of each release you have to pass through. MongoDB team is explaining all these steps.

For example here you can find how to upgrade from 2.2 to 2.4 : http://docs.mongodb.org/manual/release-notes/2.4-upgrade/#upgrade-a-sharded-cluster-from-mongodb-2-2-to-mongodb-2-4

The basic steps are:

• Upgrade all mongos instances in the cluster.
• Upgrade all 3 mongod config server instances.
• Upgrade the mongod instances for each shard, one at a time.

Once again, look at the release notes, this is should be your first step ;)