Troubleshooting
Problem
In a TSAMP environment it might come to conflicts when a TWS policy was setup and db2haicu and/or a "db2 takeover hadr" command may start resources on the same node again
Symptom
In a TSA MP environment when a TWS policy was setup and then DB2 policy using db2haicu it might be seen that a "db2 takeover hadr" command seems to be successful, but starts resources on the same node as before. The HADR primary/standby do not switch
Cause
The TWS policy defines affinity relationship against the IBM.PeerNode resources.
This prevents TSA BINDER to find the new location on the other side
Diagnosing The Problem
list the existing Affinity relationships, and verify those have IBM.PeerNode as Target:
lsrel -P Affinity
Resolving The Problem
Delete the affinity relationship:
(resource names depend on current environment, Relationship=3 means Affinity )
1) Lock affected resource groups
rgreq -o lock tws1-rg
rgreq -o lock tws2-rg
2) Remove all Affinity relationships
rmrel -s 'Relationship=3'
NOTE: If you have other Affinity relationships defined then this command cannot be used. Instead of this use
rmrel -s "Name='<Relationship name>' "
3) unlock the resource groups again
rgreq -o unlock tws1-rg
rgreq -o unlock tws2-rg
=> check that no more Affinity relationships exist against IBM.PeerNode resources:
lsrel -P Affinity
4) Restart Master IBM.RecoveryRM daemon
a). identify the node running the IBM.RecoveryRM master
lssrc -ls IBM.RecoveryRM | grep Master
b) on 'master node' kill the process
ps -ef | grep RecoveryRMd
kill -9 <pid-of-IBM.RecoveryRMd-process>
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21959728