After reboot primary and standby starts up and then they turn into catch up pending

[gilman]

Hello there,

we have configured a perfect DB2 HADR pair. After some days, we had
following problem:
After a reboot standby becomes standby, that's ok. Pimary becomes
primary, i tought db2 could do this then, when standby and primary
talks with each other, or find each other.
So long everything's ok, but then i see the state ist catch up pending
and they don't find each other.
After reboot obviousley they find each other and then tere is no more
connection. We have no firewall activated.
I only become "peer" state when i stop hadr and then start hadr....then
they comme to peer state and everythings is ok? ANy ideas? This would
be very nice and don't give a shit 'bout my english.

[Steve Pearson (news only)]

If the primary was shut down and it restarted successfully, and it was
not restarted via "start hadr .. as primary by force", then the primary
and standby must have been able to communicate and must have
successfully passed some basic handshake validations. If the two could
not connect, then the attempt to restart/activate/connect to the
primary would hang for HADR_TIMEOUT and then fail with SQL1768N reason
code 7.

If the primary was never shut down, i.e., just the standby was
rebooted, then the primary could remain as primary throughout the
event, and that would not imply anything about connectivity after the
reboot of the standby. There could be comm issues after the reboot,
and the standby would restart as a (disconnected) standby just fine.
For example, if the standby happened to get a different IP address on
the reboot (via DHCP, for example), the primary might reject the
attempt to reconnect if it was configured to expect the old IP address.

The db2diag.log files from the two databases at the time of the
reboot(s) could prove interesting. They should show all HADR state
transitions, and may point to some specific problem, e.g., comm
connection lost later for some reason, or pair validation failed.

If you can't find a cause, I suggest that you raise this with your IBM
support channel.

Regards,
- Steve P.
-----------------------
Steve Pearson
IBM DB2 UDB for LUW Development
Portland, OR, USA