Performing rolling updates in an automated Db2 high availability disaster recovery (HADR) environment

When you use the integrated High Availability (HA) feature to automate HADR, extra steps are required to update operating system or Db2® database system software, upgrade hardware, or change database configuration parameters. Use this procedure to perform a rolling upgrade in an automated HADR environment.

Before you begin

Note: The following update procedures are for an automated HADR environment. If you want to perform rolling updates on an HADR environment that is not automated, see Performing rolling updates in a Db2 high availability disaster recovery (HADR) environment.
You must have the following prerequisites ready to perform the steps that are described in the procedures section:
  • Two Db2 instances.
  • Two Db2 servers.
  • The instances are originally running at Version 11.1.1.1 or a later version. If the instances are running on version 11.1 GA, refer to this IBM® technote.
  • The instances are configured with IBM Tivoli® System Automation for Multiplatforms (SA MP) controlling HADR failover.
Note: All Db2 fix pack updates, hardware upgrades, and software upgrades must be implemented in a test environment prior to applying them to your production system.

The HADR pair must be in PEER state prior to starting the rolling update.


Restrictions

Use this procedure to perform a rolling update on your Db2 database system and update the Db2 database product software to a new fix pack level in an automated HADR environment. For example, applying a fix pack to a Db2 database product software.

  • The Db2 instances must be currently running at Version 11.1.1.1 or a later version. If the instances are running on version 11.1 GA, refer to this IBM technote.

A rolling update cannot be used to upgrade a Db2 database system from an earlier version to a later version. For example, you cannot use this procedure to upgrade from Db2 version 10.5 to Db2 version 11.1. To upgrade a Db2 server in an automated HADR environment, see Upgrading Db2 servers in an automated HADR environment .

You cannot use this procedure to update the Db2 HADR configuration parameters. Updates to the HADR configuration parameters must be made separately. Because HADR requires the parameters on the primary and standby to be the same, both the primary and standby databases might need to be deactivated and updated at the same time.

Procedure

  1. On the standby node, stop all Db2 processes:
    • deactivate db <database-name>. This command stops HADR, but retains the role.
    • db2stop force.
  2. Run the stoprpnode -f <standby node> command as root.
  3. Apply Fix Pack.
  4. On the primary node, run the startrpnode <standby node> command as root.
  5. On the standby node, start all Db2 processes:
    • db2start.
    • activate db <database-name>. This command resumes HADR but retains the role.
    • Verify that the HADR pair has established PEER state via the db2pd -hadr db <database-name> command.
  6. Perform a role-switch:
    • On the standby node, issue the db2 takeover hadr on db <database-name> command.
    • Old primary disconnects because new primary is on a higher fix pack level.
  7. On the old primary node, repeat steps 1-5 to apply the fix pack.
  8. Perform a failback to locate the HADR roles back to their original state.
    • On the standby (old primary) node issue the db2 takeover hadr on db <database-name> command.
    • Prior to starting the fix pack installation process, verify that the original primary node is the PRIMARY and verify that the HADR pair is still in PEER state via the db2pd -hadr db <database-name> command.
  9. If required, migrate the TSA domain.
    • TSA domain migration is only required if the new Db2 fix pack includes a new TSA version. It is not always the case that the new Db2 fix pack includes a new TSA version.
    • TSA domain migration is required if the active version number (AVN) does not match the installed version number (IVN). These values can be listed by running the lssrc -ls IBM.RecoveryRM |grep VN command.
    • To migrate TSA domain, issue the following command as root:
      export CT_MANAGEMENT_SCOPE=2
      runact -c IBM.PeerDomain CompleteMigration Options=0
      samctrl -m	# Type 'Y' to confirm migration
      
    • Verify that the AVN and IVN values match via the lssrc ls IBM.RecoveryRM |grep VN command.
  10. Verify that MixedVersions is set to No for the cluster manager by running the lsrpdomain command.