Upgrade a cluster in stages | RS

On an on-premises Atlas cluster, you can upgrade part of the cluster first, test the new version, and then upgrade the rest. This is the safest way to take a product upgrade on a deployment that has a failover backup, because the backup stays on the previous version until you are ready.

Staged upgrades work because a node that does not participate in cluster updates is left alone completely. It does not install the update from the primary node, and it does not catch up on its own.

📘

Staged upgrades are available only on on-premises deployments. On Cloud and FedRAMP deployments, every node always participates.

Before you begin

Decide which nodes to hold back. We recommend holding back the failover backup and some of the traffic nodes so they can continue serving traffic on the previous version. We also recommend taking a backup or VM snapshot before upgrading in case you need to revert to the previous version.

Upgrade the first part of the cluster

1. On each node that you want to hold back, go to /appliance > Updates.

2. In the Cluster Updates section, uncheck Install updates on this node together with the other nodes, then click Save.

3. On the failover backup, turn off Enable Automatic Failover (/login > Management > Failover).

4. On the primary node, go to /appliance > Updates.

5. In the Cluster Updates section, click Resync now, wait a moment, and then reload the page.

6. In the Cluster table, confirm that the Coordination column shows Not participating for each node you are holding back.

7. Start the upgrade on the primary node by clicking Install Now or Install Later.

   The update installs on the primary node and on every node that still participates. The held-back nodes are skipped.

8. Monitor progress in the Current panel and the Cluster table.

9. When the update is complete, test the upgraded nodes. They serve traffic on the new version, while the held-back nodes continue on the previous version.

Complete the upgrade

If the new version works as expected, upgrade the rest of the cluster:

1. On each held-back node, go to /appliance > Updates.

2. In the Cluster Updates section, check Install updates on this node together with the other nodes.

3. Confirm the message, and then click Save.

   Each node acts immediately instead of waiting for the next scheduled check. It installs the update that the primary node published, or, if that update is no longer published, brings itself up to the version of the primary node.

4. On the primary node, confirm that the Current panel shows Installed on every node and that the Cluster table shows the same version for every node.

5. On the failover backup, turn Enable Automatic Failover back on after it runs the same version as the primary node.

If the new version does not work as expected, the failover backup still runs the previous version, with its data from before the upgrade. While the versions differ, the failover backup receives no new data.

What to expect during a staged upgrade

The Current panel shows Installed on every node, while some nodes still run the previous version.
This is expected. The count in the Current panel includes only participating nodes. The held-back nodes are not counted. Use the Cluster table to see the version of every node.

The held-back nodes are flagged as behind the primary node.
This is expected. The Product column, and the Patches column if patch sets differ, show that the held-back nodes are behind. The flags clear as each node is brought back into participation and updated.

Failover operations stop while the failover backup runs a different version.
This is expected. The failover backup receives no new data, and the appliance alerts you that the versions differ. Failover operations resume when both appliances run the same version.