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 or 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
topic about automatic client reroute (client-side) in the DB2 Information Center.
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.
In general, if an alternate server is specified, automatic
client reroute will be enabled when a communication error is detected.
In a high availability disaster recovery (HADR) environment, it will
also be enabled if SQL1776N is returned back from
the HADR standby server.
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