Here is an example of HADR TAKEOVER with no inflight transaction
and all the log data have been replayed by standby. As shown
by the db2diag.log messages, it took more than 60 seconds from
sqlpgSwitchFromRedoToUndo() to hdrSetDbRoleAndDbType():
-----
2019-07-23-10.58.52.468428+540 I258807A558 LEVEL: Info
PID : 22675828 TID : 5143 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : DB1
HOSTNAME: hidehy1
EDUID : 5143 EDUNAME: db2loggr (DB1) 0
FUNCTION: DB2 UDB, recovery manager,
sqpLoggrEdu::sqlpgSwitchFromRedoToUndo, probe:525
DATA #1 :
Redo for forced takeover replayed all log records received from
the primary on log stream 0.
Next redo lso: 4380878783825
Next log shipping lso: 4380528317163
---- snip ---
2019-07-23-11.00.11.515486+540 E277473A1230 LEVEL: Event
PID : 22675828 TID : 16451 PROC :
db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : DB1
HOSTNAME: hidehy1
EDUID : 16451 EDUNAME: db2hadrs.0.0 (DB1) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrSetDbRoleAndDbType, probe:10020
CHANGE : HADR DATABASE ROLE/TYPE -
HADR database role set to PRIMARY (was STANDBY).
HADR database type set to PHYSICAL (was PHYSICAL).
-----
The extra time was spent allocating synchronously of all primary
log files. So the delay can vary, based on the LOGPRIMARY and
LOGFILSIZ database configuration parameters.
This issue occurs in some boundary condition, typically when the
last log file processed by the standby is a truncated log file.
This can be observed in the sqlpgSwitchFromRedoToUndo, probe:525
message, where "Next redo lso" is higher than "Next log shipping
lso" plus 1. |
