Performing rolling updates in an automated HADR environment from DB2 V11.1 GA to DB2 V11.1 FP1
This document covers some additional steps needed for those on DB2 V11.1 GA wishing to perform rolling updates to DB2 V11.1 FP1 in an automated HADR environment.
Resolving the problem
1. Run the ‘db2haicu -delete’ 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. Apply the fix pack. See the "Applying fix packs" Knowledge Center link in the Related URL section at bottom of this technote.
4. On the standby node, start all DB2 processes:
· 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
5. 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
6. On the old primary node, repeat steps 2 - 4 to apply the fix pack.
7. 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
8. Run the ‘db2haicu’ command on both nodes to configure high availability. See the "Configuring a cluster using db2haicu" Knowledge Center link in the Related URL section at the bottom of this technote.
More support for:
DB2 for Linux, UNIX and Windows
High Availability - PureScale
Software version: 11.1
Operating system(s): AIX, Linux
Software edition: Advanced Enterprise Server, Advanced Workgroup Server, Enterprise Server, Workgroup Server
Reference #: 1995136
Modified date: 07 April 2017