If either the standby database or the standby HADR is down, the standby package fails on Node2. In this case, the standby package logs a failure message in the package log and sends an email if the ALERT_MAIL_ID package attribute is set.
The primary package continues to run. Standby is not connected to the primary database, so the primary package logs a warning message, Standby disconnected and sends an email if ALERT_MAIL_ID package attribute is set. The standby package fails over to Node1. After primary HADR
If the standby package is halted manually, the primary package logs a warning message, Standby disconnected and sends an email if ALERT_MAIL_ID package attribute is set.
Event 2: Primary package fails
If the primary package fails, either because the DB2 database monitoring or the primary HADR has failed, the package fails on that node. If ROLE_MANAGEMENT attribute is set to [yes], the standby HADR package performs a role takeover and becomes the new primary database. The role takeover is done using the [by force] option. The standby package logs success or failure of the role takeover to the package log, and if ALERT_MAIL_ID package attribute is set, an email is sent to the mail ID. Simultaneously, primary package fails over to Node1. While primary package starts on Node1, standby package does a role takeover. In this case, primary package starts HADR as standby. After the new primary database is up, all database clients reconnect to this database using the Automatic Client Reroute feature of DB2 HADR. When primary package fails and the ROLE_MANAGEMENT attribute is set to [no], standby package does not perform a role takeover. If failover is enabled for the package, primary package fails over to Node1 and starts HADR as primary.
Event 3: The node on which the primary database is running crashes
Consider ROLE_MANAGEMENT attribute is set to [yes]. In this state, if Node2 crashes, the standby HADR package uses the by force option to perform a role takeover, and becomes the new primary database. Standby package logs success or failure of role takeover in the package log and if ALERT_MAIL_ID package attribute is set, email is sent to the mail ID. Simultaneously, primary package fails over to Node1. While primary package starts on Node1, the standby package completes the role takeover process. In this case, primary package starts HADR as standby. After the new primary database is up, all database clients reconnect to this database using the Automatic Client Reroute feature of DB2 HADR.
If the ROLE_MANAGEMENT attribute is set to [no], behavior is the same as in Event 2.
Event 4: Primary package is manually halted
If the primary package is halted using the cmhaltpkg command, the standby package does not perform a role takeover. The standby package continues to stay up but logs a message in the package log stating that the primary package is manually halted and sends an email to the mail ID with the Primary disconnected message. There is no other impact on the standby package when the primary package is halted manually.
Event 5: The failed primary package restarts on the primary node
This scenario is a continuation of Event 3 and 4. After the initial role takeover, the original primary package attempts to start as the primary package. The primary package fails to come up as the primary package because a role takeover was performed when the primary package went down, and the original standby package is now running as primary HADR. In this case the package attempts to come up as standby. However, if it fails to come up as standby, it halts the package but if it is successful, it performs the following tasks:
1.Syncs up with the primary HADR and retrieves all the pending DB2 database archive logs. This is a HADR feature and toolkit does not perform this task.
2.After the logs are in sync, the HADR on both nodes move to the Peer state.
Using the DB2 HADR toolkit 37