7.2. Upgrading Cluster Software

⁠7.2. Upgrading Cluster Software

There are three approaches to upgrading a cluster, each with advantages and disadvantages.

Table 7.1. Upgrade Methods

Method	Available between all versions	Can be used with Pacemaker Remote nodes	Service outage during upgrade	Service recovery during upgrade	Exercises failover logic	Allows change of messaging layer ⁠^[a]
Complete cluster shutdown	yes	yes	always	N/A	no	yes
Rolling (node by node)	no	yes	always ⁠^[b]	yes	yes	no
Detach and reattach	yes	no	only due to failure	no	no	yes
^[a] Currently, Corosync version 2 and greater is the only supported cluster stack, but other stacks have been supported by past versions, and may be supported by future versions. ^[b] Any active resources will be moved off the node being upgraded, so there will be at least a brief outage unless all resources can be migrated "live".

⁠7.2.1. Complete Cluster Shutdown

In this scenario, one shuts down all cluster nodes and resources, then upgrades all the nodes before restarting the cluster.

On each node:
1. Shutdown the cluster software (pacemaker and the messaging layer).
2. Upgrade the Pacemaker software. This may also include upgrading the messaging layer and/or the underlying operating system.
3. Check the configuration with the crm_verify tool.
On each node:
1. Start the cluster software. Currently, only Corosync version 2 and greater is supported as the cluster layer, but if another stack is supported in the future, the stack does not need to be the same one before the upgrade.

One variation of this approach is to build a new cluster on new hosts. This allows the new version to be tested beforehand, and minimizes downtime by having the new nodes ready to be placed in production as soon as the old nodes are shut down.