Troubleshooting
Problem
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
Procedure
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:
· 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
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.
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:
· 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
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.
Related Information
[{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"High Availability - PureScale","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}],"Version":"11.1","Edition":"Advanced Enterprise Server;Advanced Workgroup Server;Enterprise Server;Workgroup Server","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Was this topic helpful?
Document Information
Modified date:
21 May 2023
UID
swg21995136