How to upgrade (refresh) a sharded cluster¶

This guide goes over the steps to perform a minor in-place upgrade via juju refresh for a sharded cluster. Going forward, we will use the word “refresh” instead of “upgrade”.

Before refreshing¶

Ensure your MongoDB deployment is healthy (active and idle), and not performing any long-running operations such as creating a backup.

Do not perform any extraordinary operations on your cluster while refreshing, as it can lead the cluster into inconsistent states. Some dangerous operations could be:

Adding or removing units
Creating or destroying relations
Upgrading other related applications simultaneously

Make sure to have created and tested a backup of your data. See: How to create a backup.

Take note of your MongoDB application’s current revision:

juju status | grep <app-name> | head -1 | awk '{print $5}'

Save this number in case you need to roll back your application.

Refresh the config-server¶

Upgrade your config-server following the instructions in How to upgrade (refresh) a replica set.

Warning

Do not proceed if this step was not successful. If your refresh failed, roll back the cluster.

Begin the refresh¶

After successfully refreshing your config-server, the next step is to upgrade your hsards.

Refresh each shard one at a time. Start by refreshing the first shard, and follow the instructions in How to upgrade (refresh) a replica set.

Only refresh the next shard when the current refresh succeeds - i.e. all units show active and idle statuses.

Warning

Do not proceed if an upgrade of a shard fails. If an upgrade fails, roll back the entire cluster.

Upgrade mongos application¶

Next, upgrade any integrated mongos application.

See: