You can use automatic client reroute (ACR) with high availability
disaster recovery (HADR) to transfer client application requests from
a failed database server to a standby database server.
Restrictions
- Rerouting is only possible when an alternate database location
has been specified at the server.
- Automatic client reroute is only supported with TCP/IP protocol.
- You cannot use ACR if you have client
affinity enabled.
Configuration details
- Use the UPDATE ALTERNATE SERVER FOR DATABASE command
to enable automatic client reroute.
- Automatic client reroute does not use the hadr_remote_host and hadr_remote_svc database
configuration parameters.
- You can only specify one standby database
for automatic client reroute.
- The alternate host location is stored in the system database
directory file at the server.
- If automatic client reroute is not enabled, client applications
receive error message SQL30081N, and no further attempts
are made to establish a connection with the server.
Setting up automatic client reroute with HADR
The
system is set up as follows:
- There is a client where database MUSIC is cataloged
as being located at host HORNET with port number 456, which is assigned
by the svcename configuration parameter.
- Database MUSIC is the primary database and its corresponding standby
database, also MUSIC, resides on host MONTERO with port number 456,
which is assigned by the svcename configuration
parameter.
To enable automatic client reroute, update the alternate server
for database MUSIC on host HORNET:
DB2 UPDATE ALTERNATE SERVER FOR DATABASE music USING HOSTNAME montero PORT 456
After
this command is issued, the client must successfully connect to host
HORNET to obtain the alternate server information. Then, if a communication
error occurs between the client and database MUSIC at host HORNET,
the client first attempts to reconnect to database MUSIC at host
HORNET. If this fails, the client then attempts to establish a connection
with the standby database MUSIC on host MONTERO.
To
ensure that ACR can still be used in the event of a role switch, configure
the primary database as the alternate server for the standby by issuing
the following command on the standby:
DB2 UPDATE ALTERNATE SERVER FOR DATABASE music USING HOSTNAME hornet PORT 456
Setting up automatic client
reroute with HADR in a DB2 pureScale environment
A
user wants to set up ACR for a three-member
DB2® pureScale® instance
that is configured with HADR. The system is set up as follows:
- Database name: hadr_db
- Instance owner on all hosts: db2inst
- TCP port that is used for HADR primary-standby communication:
4000
- TCP port that is used for SQL client/server communication: 8000
- Hosts for cluster
caching facilities (with
IDs 128 and 129) and members (with
IDs 0, 1, 2, and 3) on the primary: cfp0, cfp1, p0, p1, p2, and p3
- Hosts for cluster
caching facilities and members on
the standby: cfs0, cfs1, s0, s1, s2, and s3
The user issues the following command from
member 0 on the primary:
DB2 UPDATE ALTERNATE SERVER FOR DATABASE hadr_db USING HOSTNAME s0 PORT 8000
The
first time a client connects to the primary, the server returns the
addresses of all members in the primary cluster and the alternate
server address (s0:8000), which is member 0 of the standby cluster.
If a client cannot connect to one member on the primary cluster, it
tries to connect to another member on the primary. If the client cannot
connect to any member on the primary, it tries to connect to member
0 on the standby. The user could further improve availability by using
a connection distributor or multi-home DNS entry, which includes multiple
members on the standby, as the alternate server address.
To
ensure that ACR can still be used in the event of a role switch, the
user also configures the primary cluster as the alternate server for
the standby by issuing the following command from member 0 on the
standby:
DB2 UPDATE ALTERNATE SERVER FOR DATABASE hadr_db USING HOSTNAME p0 PORT 8000
DB2 10.5 for Linux, UNIX, and Windows