Applying rolling updates to a Pacemaker-managed Db2 Mutual Failover environment

When using the integrated Mutual Failover High Availability (HA) feature with Pacemaker, you can apply rolling updates on the operating system, the Db2 database system software., the hardware, and database configuration parameters.

Before you begin

Ensure that the following configuration is in place before applying your updates:

You have a Mutual Failover Db2® instance running on a Pacemaker-managed Linux cluster.
There are two Db2 servers running version 11.5.8 or later in the instance.

Note: All Db2 fix pack updates, hardware upgrades, and software upgrades must be applied to a test environment and be operating correctly before being applied to your production system.

Use this procedure to update your Db2 database system and Db2 database product software,to a new fix pack level in a Pacemaker-managed Mutual Failover Db2 instance.

Important: If the Pacemaker product that is managing the cluster is provided by a vendor other than IBM, you must remove all cluster resources by following the procedures outlined from the Pacemaker supplier. When the resource are removed you can then recreate then from the IBM-provided Pacemaker cluster software stack by using the db2cm utility. For more information, see Configuring a Mutual Failover environment using the Db2 cluster manager (db2cm) utility.

Procedure

As the instance user, log in to the host where instance home directory is mounted and stop all Db2 processes for all instances
```
db2stop
```

As the root user, stop the Pacemaker and Corosync processes on both hosts:

systemctl stop pacemaker
systemctl stop corosync
systemctl stop corosync-qdevice

Apply any fix pack that is needed. For more information, see Installing offline fix pack updates to existing Db2 database products (Linux®® and UNIX).

Important: Be sure to run the installfixpack command on both hosts and the db2iupdt command on only the host where the instance shared home directory is mounted.
If the Qdevice is configured, log in to the Qdevice host as the root user and stop the corosync-qnetd process:
1. Run systemctl stop corosync-qnetd
2. As the root user, update the corosync-qnetd package provided by IBM on the Qdevice host:
  For RHEL Systems:
```
dnf upgrade <Db2_image>/db2/<platform>/pcmk/Linux/<OS_distribution>/<architecture>/corosync-qnetd*
```
  For SLES systems:
```
zypper in --allow-unsigned-rpm <Db2_image>/db2/<platform>/pcmk/Linux/<OS_distribution>/<architecture>/corosync-qnetd*
```
3. Start the corosync-qnetd process:
```
systemctl start corosync-qnetd
```
On both hosts, log in as the root user and start the Pacemaker and Corosync processes:
```
systemctl start pacemaker
systemctl start corosync
systemctl start corosync-qdevice
```
Note: If both hosts were rebooted after stopping the Db2, Pacemaker and Corosync processes, then the file system is not mounted and remains as such even after restarting the Pacemaker and Corosync processes. Run the db2cm -enable -all command to allow Pacemaker to bring the file system and partition back up. This action removes the need to run db2start.
Start Db2 processes on the host that has the instance shared directory mounted:
```
db2start
```