When the HADR standby database (or standby host, or the network)
is in abnormal state, it might take up to HADR_TIMEOUT for the
HADR primary to detect the lost of connectivity with the
standby. During this time, transactions running on the primary
database is blocked due to HADR_SYNCMODE and PEER state
semantics. Furthermore, if HADR_PEER_WINDOW is configured, the
transactions will be blocked for an additional HADR_PEER_WINDOW
time. However, that is the maximum time the transactions should
be blocked. This problem can cause transactions to be blocked
longer than the maximum HADR_TIMEOUT + HADR_PEER_WINDOW.
Sample db2diag.log messages from the primary are shown below
(with HADR_TIMEOUT and HADR_PEER_WINDOW are both configured to
be 110) :
2019-12-02-15.09.10.069495-300 I238486882A433 LEVEL:
Warning
PID : 13369670 TID : 15530 PROC :
db2sysc 0
INSTANCE: db2inst NODE : 000 DB :
SAMPLE
HOSTNAME: hostname1
EDUID : 15530 EDUNAME: db2hadrp.0.1 (SAMPLE) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrCloseConn, probe:30595
DATA #1 :
Peer window end time : 1575317460
...
2019-12-02-15.11.59.961951-300 I238489927A428 LEVEL:
Warning
PID : 13369670 TID : 15530 PROC :
db2sysc 0
INSTANCE: db2inst NODE : 000 DB :
SAMPLE
HOSTNAME: hostname1
EDUID : 15530 EDUNAME: db2hadrp.0.1 (SAMPLE) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrEduAcceptEvent, probe:20202
MESSAGE : Peer window ends. Peer window expired.
In the above example, the first message is printed after primary
has detected the lost of connection to standby (ie. after
HADR_TIMEOUT). It printed the peer window end time (the value
1575317460 translates to 2019-12-02-20.11.0 GMT, or
2019-12-02-15.11.0 local, ie. 2019-12-02-15.09.10 + 110
seconds). However, the second message is when the peer window
actually expired, about 170 seconds later, instead of expected
110 seconds. |
