IBM Support

Changes to procedure for Performing rolling updates in an automated high availability disaster recovery (HADR) environment

Technote (FAQ)


Question

Are there any changes to the procedure for Performing rolling updates in an automated high availability disaster recovery (HADR) environment?

Answer

The DB2/LUW v9.7 document titled "Rolling upgrade in an automated High Availability Disaster Recovery (HADR) environment", and the equivalent v10.1, and v10.5 Knowledge Center documents titled "Performing rolling updates in an automated high availability disaster recovery (HADR) environment" require some procedure changes. These changes will be reflected within the v11.1 Knowledge Center document, but not within the Knowledge Center documents in previous versions.

If you are using DB2 versions prior to v11.1, please reference the procedure within the v11.1 document since the same procedure applies to all previous versions as well.

For completeness, the new procedure is included in this technote as well:


Procedure
1. Run the ‘db2haicu -disable’ command on both nodes.

2. On the standby node, stop all DB2 processes:
· deactivate db <database-name> (this will stop HADR, but retain the role)
· db2stop force

3. Run the ‘stoprpnode -f <standby node>’ command as root.

4. Apply the fix pack. See the "Applying fix packs" Knowledge Center link in the Related URL section at bottom of this technote.

5. On the primary node, run the ‘startrpnode <standby node>’ command as root.

6. On the standby node, start all DB2 processes:
· db2start
· activate db <database-name> (this will resume HADR and retain the role)
· Verify HADR pair has established PEER state via the ‘db2pd -hadr db <database-name>’ command

7. Perform a role-switch:
· On the standby node issue: ‘db2 takeover hadr on db <database-name>’
· At this point, old primary will disconnect because new primary is on a higher fixpack level

8. On the old primary node, repeat steps 2-6 to apply the fix pack.

9. Perform a failback to swap the HADR roles back to their original state.
◦ On the standby (old primary) node issue: ‘db2 takeover hadr on db <database-name>’
◦ Verify the original primary node (before starting fix pack install process) is the PRIMARY and the HADR pair is still in PEER state via the ‘db2pd -hadr db <database-name>’ command

10. Migrate the TSA domain (if required)
◦ TSA domain migration is only required if the new DB2 fix pack includes a new TSA version (which is not always the case)
◦ 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 the TSA domain issue the following commands 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

11. Verify that MixedVersions is set to No for the cluster manager by running the ‘lsrpdomain’ command

12. Run the ‘db2haicu’ command on both nodes and select the option to re-enable automation.

Related information

Applying fix packs
9.7 Knowledge Center doc
10.1 Knowledge Center doc
10.5 Knowledge Center doc

Document information

More support for: DB2 for Linux, UNIX and Windows
High Availability - PureScale

Software version: 9.7, 10.1, 10.5

Operating system(s): AIX, Linux

Software edition: Advanced Enterprise Server, Advanced Workgroup Server, Enterprise Server, Workgroup Server

Reference #: 1994790

Modified date: 01 December 2016