Alternate groups for connections to Db2 from non-Java clients

To improve high availability for non-Java clients in Version 9.7 Fix Pack 5 or later fix pack releases, use alternate groups as an additional failover mechanism for automatic client rerouting when connectivity to the current group cannot be re-established.

By default, non-Java clients have the automatic client reroute (ACR) enabled. This capability provides automatic failover to alternate servers within the current group when connectivity to a server cannot be re-established.

In addition to this ACR capability, you can define alternate groups as failover targets when connectivity to the current group cannot be established. To define alternate groups for non-Java clients:
  • Define a <database> element for each alternate group inside the <alternategroup> element in the <acr> section of the db2dsdriver.cfg file. Do not specify <parameter> elements inside the <database> element, parameter settings are inherited from the primary group. You can define multiple <database> elements inside the <alternategroup> element. The order of the <database> elements is the order that is used during failover.
  • If you want to suppress error messages from failover connections to the alternate group, set the enableAlternateGroupSeamlessACR parameter to true in <alternategroup> element.

The default ACR retry time period is 10 minutes. When you define alternate groups, that time period is reduced to 2 minutes.

When a non-Java client is connected to an alternate group, all the connection settings and the parameter settings for the <database> element in the primary group are inherited by the connection to the database in the alternate group.

After a non-Java client is connected to a database in the alternate group, no failback to the primary group is provided. To connect to the primary group again, the application or client must be restarted.

Alternate groups are only supported for ACR and workload balancing. If client affinities is configured, alternate group definitions are ignored.

Examples

Here is an example of alternate group definitions in the db2dsdriver.cfg file:
<dsncollection>
  <dsn alias="mydsn2" name="mydb2" host="myserver2.ibm.com" port="5912">
  ...
</dsncollection>

<databases>
  <database name="mydb2" host="myserver2.ibm.com" port="5912">
   <parameter name="IsolationLevel" value="4"/>
   ...
   <wlb>
     <parameter name="enableWLB" value="true"/>
   </wlb>
   <acr>
    ... (ACR parameters definition)
    <alternateserverlist>
      <server name="server1" hostname="db2luwa.luw.ibm.com" port="5912">
      </server>
      <server name="server2" hostname="db2luwb.luw.ibm.com" port="5912">
      </server>
    </alternateserverlist>
    <alternategroup>
     <parameter name="enableAlternateGroupSeamlessACR" value="true"/>
     <database name="mydb3" host="myserver3.ibm.com" port="5912">
     </database>
     <database name="mydb4" host="myserver4.ibm.com" port="5912">
     </database>
     </alternategroup>
   </acr>
   </database> 

   <database name="mydb3" host="myserver3.ibm.com" port="5912">
    <parameter name="IsolationLevel" value="2"/>
    <acr>
     <parameter name="enableACR" value="true"/>
    <alternateserverlist>
      <server name="server4" hostname="db2luwd.luw.ibm.com" port="5912">
      </server>
    </alternateserverlist>
    <alternategroup>
     <parameter name="enableAlternateGroupSeamlessACR" value="true"/>
     <database name="mydb5" host="myserver5.ibm.com" port="5912">
     </database>
     </alternategroup>
    </acr>
   ...
   </database> 
</databases>
The following example scenarios demonstrate how automatic client rerouting works for alternate groups. The details about ACR failover to the current group are not covered in these scenarios to focus on the alternate groups failover details. These scenarios use the db2dsdriver.cfg sample file that is described in the previous paragraph.
First connection to the primary group fails
After a non-Java client fails to connect to the primary group on its first attempt, automatic client reroute failover to alternate servers in the current group also fails. In this example, the client performs the following actions:
  1. The client fails to connect to mydb2.
  2. The client fails to connect to server1.
  3. The client fails to connect to server2.
  4. The client tries to connect to an alternate group listed in the <alternategroup> section of the db2dsdriver.cfg file in the order specified in this file:
    1. The client fails to connect to mydb3.
    2. The client successfully connects to mydb4.

After connecting to mydb4, the rules for seamless or non-seamless behavior still apply. If the client would not be able to connect to mydb4, it would receive the SQL30081N error message.

Subsequent connection or existing connection to the primary server fails
After a non-Java client loses its connection to mydb2, automatic client reroute failover to alternate servers in the current group also fails. In this example, the client performs the following actions:
  1. The client fails to connect to server1.
  2. The client fails to connect to server2.
  3. The client tries to connect to an alternate group listed in the <alternategroup> section of the db2dsdriver.cfg file in the order specified in this file:
    1. The client successfully connects to mydb3.

After connecting to mydb3, the rules for seamless or non-seamless behavior still apply.

Existing connection to an alternate group fails
A non-Java client fails to connect to mydb2, automatic client reroute failover to alternate servers in the current group also fails, and then it successfully connects to the mydb3 alternate group.

After the client loses its connection to mydb3, it attempts to connect to mydb4. In this example, the client fails to connect to mydb4.

The client receives the SQL30081N error message. You must restart the client or the application to try connecting to the primary group again.