|
Problem IT25869
|
Status: Closed |
HADR GRACEFUL TAKEOVER ON PURESCALE COULD FAIL WITH SQL1770N RC7WHILE OLD PRIMARY DATABASE IS SWITCHING ROLE.
|
| product: |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 |
| Problem description: |
It's possible that during HADR graceful takeover in pureScale
environment, standby database could timeout and fail with
SQL1770 reason code 7, after the primary has processed the
graceful takeover and switched its role to standby. This
results in both clusters having the HADR role as STANDBY. The
following diagnostic message can be found in db2diag.log on
standby:
2018-07-17-02.51.23.583987-240 I429271E669 LEVEL:
Error
PID : 28043 TID : 140391936419584 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : LIVE
APPHDL : 0-40808 APPID: *N0.db2inst1.180717064855
AUTHID : DB2INST1 HOSTNAME: host2
EDUID : 5388 EDUNAME: db2agent (LIVE) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrCoordinateTakeover, probe:47150
MESSAGE : ZRC=0x8280001B=-2105540581=HDR_ZRC_COMM_CLOSED
"Communication with HADR partner was lost"
DATA #1 : String, 54 bytes
No viable members found for commit, aborting takeover. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* PURESCALE *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to release inclusive of this fix. Refer to SYSROUTE *
* APAR. *
**************************************************************** |
| Local Fix: |
To complete the failover, issue TAKEOVER BY FORCE on the
original standby database. This is safe because the original
primary had completed the graceful takeover processing and
switched its role to standby. There will be no data lost and
the two clusters will be able to form HADR connection after the
forced takeover. |
| Solution |
|
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner :
follow-up : IT25994 |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 31.07.2018
26.10.2018
26.10.2018 |
| Problem solved at the following versions (IBM BugInfos) |
|
| Problem solved according to the fixlist(s) of the following version(s) |
