DB2 10.5 for Linux, UNIX, and Windows

Automatic client reroute description and setup

The main goal of the automatic client reroute feature is to enable an IBM® Data Server Client application to recover from a loss of communications so that the application can continue its work with minimal interruption. As the name suggests, rerouting is central to the support of continuous operations, but rerouting is only possible when there is an alternate location that is identified to the client connection.

The automatic client reroute feature could be used within the following configurable environments if the server is DB2® for Linux, UNIX, and Windows :

DB2 Enterprise Server Edition with a partitioned database environment
DB2 Enterprise Server Edition with the IBM DB2 pureScale® Feature
InfoSphere® Replication Server
IBM PowerHA® SystemMirror for AIX®
High availability disaster recovery (HADR)
Automatic client reroute works in conjunction with HADR and the DB2 pureScale Feature to allow a client application to continue its work with minimal interruption after a failover of the database being accessed.

The seamless automatic client reroute feature is required in the following configuration if the database server is on System i® or System z®:

IBM data server client connects to a z/OS® or i5/OS™ system through a DB2 Connect™ server which has an alternate server. The automatic client reroute is used between the IBM Data Server Client and two DB2 Connect servers.
DB2 Connect clients or server products accessing a DB2 for z/OS Parallel Sysplex® data sharing environment. Automatic client reroute is used between DB2 Connect and the z/OS Parallel Sysplex system. The automatic client reroute feature supports seamless failover between a DB2 Connect-licensed client and the Parallel Sysplex. For more information about seamless failover, see the related links.

In the case of the DB2 Connect server and its alternate, because there is no requirement for the synchronization of local databases, you only need to ensure that both the original and alternate DB2 Connect servers have the target host or System i database cataloged in such a way that it is accessible using an identical database alias.

In order for the DB2 database system to have the ability to recover from a loss of communications, an alternative server location must be specified before the loss of communication occurs. The UPDATE ALTERNATE SERVER FOR DATABASE command is used to define the alternate server location on a particular database.

After you have specified the alternate server location on a particular database at the server instance, the alternate server location information is returned to the IBM data server client as part of the connection process. In the case of using automatic client reroute between DB2 Connect clients or server products and a host or System i database server, the remote server must provide one or more alternate addresses for itself. In the case of DB2 for z/OS, multiple addresses are known if the database is a Sysplex data sharing environment. Therefore an alternate server does not need to be cataloged on DB2 Connect. If communication between the client and the server is lost for any reason, the IBM Data Server Client will attempt to reestablish the connection by using the alternate server information. The IBM data server client will attempt to reconnect with a database server which could be the original server, and alternate server listed in the database directory file at the server, or an alternate server that is in the server list returned by the z/OS Parallel Sysplex system. The timing of these attempts to reestablish a connection varies from very rapid attempts initially to a gradual lengthening of the intervals between the attempts.

After a connection is successful, SQL30108N is returned to indicate that a database connection has been reestablished following the communication failure. The hostname or IP address and service name or port number are returned. The IBM data server client only returns the error for the original communications failure to the application if the reestablishment of the client communications is not possible to either the original or alternative server.

In V10.1 Fix Pack 2 and later fix packs, when connecting to the DB2 for z/OS data sharing group with the workload balance (WLB) feature enabled, non-seamless ACR feature behavior has changed:

The CLI driver does not immediately look for a new transport upon a connection failure. The CLI driver allocates a transport if the application resubmits the SET statement (special registers) or the SQL statement. When the non-seamless ACR feature is enabled and the WLB feature is disabled, however, the CLI driver immediately looks for a new transport and reconnects to the next available member.
SQL30108N returns twice to the application if the CLI driver fails to reconnect to members of the primary group and must switch to the alternate group. The error is returned twice when the alternate group is specified in the db2dsdriver.cfg file with the alternategroup parameter and the enableAlternateGroupSeamlessAcr is set to FALSE. The first SQL30108N error with reason code 2 is returned when the existing connection to a member in the current group fails. The second SQL30108N error with reason code 4 is returned when all the connection attempts to all members in the existing primary group fail. The application can then resubmit the SET statement or the SQL statement again for the second time if reconnecting to the alternate group is warranted. The CLI driver tracks the failed member on a same connection handle when the ACR connection error (SQL30108N) is returned to avoid resubmitting the statement to the failed member.
Note: SQL30108N is not returned twice in the following scenarios:
- When the DB2 Connect server is used as a gateway.
- When the ACR feature is explicitly enabled without enabling the WLB feature.

When connecting to the DB2 for z/OS data sharing group, the seamless ACR feature and the WLB feature should not be disabled unless directed by IBM support.

Note the following considerations involving alternate server connectivity in a DB2 Connect server environment:

When using a DB2 Connect server for providing access to a host or System i database on behalf of both remote and local clients, confusion can arise regarding alternate server connectivity information in a system database directory entry. To minimize this confusion, consider cataloging two entries in the system database directory to represent the same host or System i database. Catalog one entry for remote clients and catalog another for local clients.
Any Parallel Sysplex information that is returned from a target DB2 for z/OS server is kept only in cache at the DB2 Connect server. Only one alternate server is written to disk. When multiple alternates or multiple active servers exist, the information is only maintained in memory and is lost when the process terminates.

Workload balancing and automatic client reroute require the client to have entries for each member in the cluster present in the /etc/hosts file. For example:

10.10.10.1 hostname01.linux hostname01
10.10.10.2 hostname02.linux hostname02

In general, if an alternate server is specified, automatic client reroute is enabled when a communication error is detected. In a high availability disaster recovery (HADR) environment, it is also enabled if SQL1776N is returned back from the HADR standby server.

HADR and DB2 pureScale considerations

When you establish a connection to one member in a DB2 pureScale instance, the server list that is returned contains information not only about all of the members of that instance, but also a hostname and port for the DB2 pureScale instance on the alternate server. If a client cannot connect to one member in the DB2 pureScale instance (or if HADR is configured, to a member on the primary database), it tries another. If it cannot connect to any member, it tries the DB2 pureScale instance at the specified alternate server address (in an HADR environment, the standby database). For better availability, you can use a connection distributor or multi-home DNS entry as alternate server address, but ensure that the distributor or multi-home DNS entry are configured to include multiple members of the alternate server.

Although it is possible to list only one member for each alternate server, clients cannot access the cluster if the listed member is offline, so it is strongly recommended that you define multiple members from the cluster using alternate group method. See the "Related links" for information on how to do this.

Other reroute options include:

Client affinity: List the primary and standby members so that the client tries both. Client affinity and ACR cannot be used together. The alternate server specifies by ACR is ignored when client affinity is enabled. Alternate groups cannot be defined when client affinity is enabled. See the "Client affinities for DB2 for Linux, UNIX, and Windows" topic for information.
Virtual IP: Define a virtual IP address that always points to the current primary server.