HADR standby replay in a Db2 pureScale environment
In a Db2 pureScale environment, only one member of the HADR standby cluster replays logs, and other members remain inactive. Members in the HADR primary cluster ship their logs to the replay member directly by using a TCP connection or indirectly through assisted remote catchup.
When a standby database is started, standby replay service is activated on the member that is designated as the preferred replay member if the Db2 instance is online on the member. Otherwise, replay is activated on another member. There is no way to control the selection among non preferred members; however, any member that is running in restart light mode (that is, a member that is not active on its home host) is given the lowest priority. Even though the preferred replay member designation is persistent, if replay is active on another member because the preferred replay member was not available, replay does not automatically revert to the preferred member when that member becomes available. The only way to force replay onto the preferred replay member is to deactivate and reactivate HADR on the standby.
Because the replay member on the standby replays logs that are generated by all members on the primary, there is a possibility that it can become a bottleneck. To avoid a potential impact, you should select the member with more resources, such as CPU and memory, as the preferred replay member. You implicitly designate the preferred replay member by issuing the START HADR command on it. The member from which you issue the START HADR AS STANDBY command is the preferred replay member on the standby cluster; the member from which you issue the START HADR AS PRIMARY command is the preferred replay member on the primary cluster. The status of preferred replay member on the primary takes effect only when the primary becomes a standby
If the current replay member goes down abnormally (for example, as a result of a software or hardware failure) or normally (for example, as a result of a user command to deactivate the particular member), replay is automatically migrated to another member. If the current replay member goes down abnormally, member crash recovery occurs, and a member is selected to resume replay, with preference to the preferred replay member during the selection (the old replay member might or might not be reselected). As long as there is one online member in the standby cluster, replay continues. To stop replay, deactivate the whole standby database.
db2pd -hadr -db DB_name -allmembers
In
the output, only the current replay member has HADR information; all
non-replay members show Database DB_name not
activated on database member X.