DB2 10.5 for Linux, UNIX, and Windows

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.

You can find out which member is the current replay member from the primary or the standby. On the primary, use the db2pd command with the -hadr parameter or the MON_GET_HADR table function. The replay member is indicated in the STANDBY_MEMBER field. If you want to determine the current replay member from the standby, you can use only the db2pd command because the table function cannot be called from a standby in a DB2 pureScale environment. Because you do not know which replay member is active, you must issue the following command:

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.