hadr_peer_window - HADR peer window configuration parameter
When you set hadr_peer_window to a non-zero time value, then a HADR primary-standby database pair continues to behave as though still in peer state, for the configured amount of time, if the primary database loses connection with the standby database. This helps ensure data consistency.
- Configuration type:
- Database
- Parameter type:
- Configurable1
- Default [range]:
- 0 [0 − 4 294 967 295]
- Unit of measure:
- Seconds
- Upgrade Note:
- If you are upgrading from a Version 9.8 Fix Pack 4 Db2® pureScale® environment or earlier, the value of hadr_peer_window is set to the value on member 0.
If you have not configured the hadr_target_list configuration parameter, the value for hadr_peer_window needs to be the same on both primary and standby databases. When hadr_target_list is set, the first standby listed (the principal standby) uses the primary's setting for hadr_peer_window and any setting for hadr_peer_window on the principal or auxiliary standbys is ignored unless one of them becomes the primary.
A recommended minimum value is 120 seconds.
Db2 pureScale does not support non-zero values for the hadr_peer_window database configuration parameter. Attempts to set hadr_peer_window to a non-zero value in a Db2 pureScale instance fail with a warning, and the START HADR command fails if hadr_peer_window is already a non-zero value in a Db2 pureScale instance.
The peer window feature requires the hadr_syncmode database configuration to be set to SYNC or NEARSYNC. When the hadr_syncmode database is set to ASYNC or SUPERASYNC, the hadr_peer_window database configuration is ignored.
To avoid impacting the availability of the primary database when the standby database is intentionally shut down, for example, for maintenance, the peer window is not invoked if the standby database is explicitly deactivated while the HADR pair is in peer state.
The TAKEOVER HADR command with the PEER WINDOW ONLY option launches a takeover operation only if the HADR standby is presently inside the defined peer window.
The takeover operation with the hadr_peer_window parameter might behave incorrectly if the primary database clock and the standby database clock are not synchronized to within 5 seconds of each other. That is, the operation might succeed when it should fail, or fail when it should succeed. You should use a time synchronization service (for example, NTP) to keep the clocks synchronized to the same source.
On the standby database, the peer window end time is a time specified in the last heartbeat message that the standby received from the primary database, and is not directly related to when the standby detects loss of the connection.