Enabling the database connection hang detection feature for automated HADR

Starting in version 11.5.6, the database connection hang detection feature can be enabled for automated HADR environments with both TSA and Pacemaker.

For users on version 11.5.6, refer to the database connection hang detection feature for more information.

Before you begin

This feature can be enabled for automated HADR environments with TSA or Pacemaker only. For more information on configuring a clustered HADR environment, refer to:

What to do next

In an automated HADR environment, the database connection hang detection feature can be enabled by setting the DB2_HADR_HANG_DETECTION environment variable in the instance owner’s Db2 profile on both HADR hosts. For example, if you have an automated HADR environment that is deployed across hosts hostA and hostB, then this feature can be enabled by adding the following line to instance owner’s $HOME/sqllib/userprofile file on both hosts:
export DB2_HADR_HANG_DETECTION=CONNECT
So long as this environment variable is set when logging in to the instance owner, then this feature is enabled. Furthermore, if certain SQL error codes are expected to be returned when attempting to connect to the primary HADR database through the instance owner and it is undesired to trigger a failover when a database connection encounters this SQL error code, then the following environment variable can also be set:
export DB2_HADR_HANG_SQL_BYPASS=SQL1040N
Note:

If using Kerberos or other GSSAPI plug-in authentication, you need to have the instance owner logged in to that authentication method before the connection attempt. In this case, the automation script which performs the database connection attempt may need to be manually modified to log in the instance owner to the authentication method.

For TSA, the /usr/sbin/rsct/sapolicies/db2/hadrV115_start.ksh script is used for database connection attempts.

For Pacemaker, the /usr/lib/ocf/resource.d/heartbeat/db2hadr script is used for database connection attempts.