DB2 Version 10.1 for Linux, UNIX, and Windows

HADR log spooling

The high availability disaster recovery (HADR) log spooling feature allows transactions on primary to make progress without having to wait for the log replay on the standby. When this feature is enabled, log data sent by the primary is spooled, or written, to disk on the standby, and that log data is later read by log replay.

Log spooling, which is enabled by setting the hadr_spool_limit database configuration parameter, is an improvement to the HADR feature. When replay is slow, it is possible that new transactions on the primary can be blocked because it is not able to send log data to the standby system if there is no room in the buffer to receive the data. The log spooling feature means that the standby is not limited by the size of its buffer. When there is an increase in data received that cannot be contained in the buffer, the log replay reads the data from disk. This allows the system to better tolerate either a spike in transaction volume on the primary, or a slow down of log replay (due to the replay of particular type of log records) on the standby.

This feature could potentially lead to a larger gap between the log position of received logs on the standby and the log replay position on the standby, which can lead to longer takeover time. Use the db2pd command with the -hadr option or the MON_GET_HADR table function to monitor this gap by comparing the STANDBY_LOG_POS field, which shows receive position, and the STANDBY_REPLAY_LOG_POS field. You should consider your spool limit setting carefully because the old standby cannot start up as the new primary and receive transactions until the replay of the spooled logs has finished.