Couple of HADR questions

[Marc]

Hi,

I'm working with a customer that is trying to find a solution to
provide geographical redundancy. Our application is currently using
IBM DB2 v8.2. I have a couple of questions with regards to HADR:

1. DB2 HADR (Can it be used to support geographical redundancy in a
nested fashion (ie. Synchronous HADR at a site, and ASYNCRONOUS
between sites using the same instances/databases). If so how would we
set it up?

2. DB2 HADR (Is the JDBC configuration any different then when a
single DB2 instance is used?) How is the JDBC driver configured (using
the jdbc connection string) to point to all the DB2 HADR nodes?
Thanks,
Marc

[Steve Pearson (news only)]

HADR itself does not presently support multiple standby sites for one
database. However, the kind of configuration you discuss can be
supported by a combination of traditional failover (i.e.,
shared/multi-ported disk plus cluster manager) locally and HADR across
the distance.

That is, you can configure the HADR primary on a cluster that supports
in-cluster failover for the DB2 server, while the HADR standby is
configured at a remote site (either w/ or w/o local failover for the
standby, but of course we prefer to see analogous configuration of the
standby).

Regarding JDBC configuration, I think you are probably asking about how
to set up Automatic Client Reroute for that client. ACR can be set up
on the server for all clients, but the universal driver also provides
the ability to set it up at the client itself (helpful in some cases,
as the server-side support doesn't kick in until a first successful
connection is made by the client whereas the driver can reroute if the
very first connection attempt itself fails).

Here are a few references for ACR, including some driver specific setup
info:

JDBC driver side:
* http://www-1.ibm.com/support/docview...id=swg21177732
* Search for string "Rerouting DB2 Universal JDBC driver clients" in
the right-hand panel here:
http://publib.boulder.ibm.com/infoce...e/r0012130.htm

Server side:
http://publib.boulder.ibm.com/infoce...n/c0011423.htm

New (general) developerWorks article on ACR:
http://www-128.ibm.com/developerwork...512zikopoulos/

Regards,
- Steve P.
--------------------------
Steve Pearson
IBM DB2 UDB for LUW Development
Portland, OR, USA

[Marc]

Steve thanks for the quick response.

Additional comments to my original questions:

1. How would we setup a DB2 cluster with in-cluster failover if we're
not using HADR?

2. You're correct. I was looking for specifics on how the client would
connect when the very first connection attemps itself fails. Can the
driver use DNS with multiple A records (one pointing to the primary and
the other to the alternate location?).

Much appreciated,
Thanks,
Marc

[Mark A]

"Marc" <mb****@magma.ca> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Steve thanks for the quick response.

Additional comments to my original questions:

1. How would we setup a DB2 cluster with in-cluster failover if we're
not using HADR?

2. You're correct. I was looking for specifics on how the client would
connect when the very first connection attemps itself fails. Can the
driver use DNS with multiple A records (one pointing to the primary and
the other to the alternate location?).

Much appreciated,
Thanks,
Marc

The type 2 driver does automatic client reroute without any coding changes.
The type 4 driver requires coding changes to persist the alternate server
location. Automatic client reroute works independent of HADR for any
database where you want alternate server connection information.

With both the type 2 and type 4 drivers, if a HADR takeover has occurred,
the application will receive a specific SQL error message that indicates
that the application has automatically reconnected and the last SQL
statement has rolled back, so the application has to retry the failed SQL
statement again, which will work on the standby database (which has now been
switched to primary).

[Steve Pearson (news only)]

1. How would we setup a DB2 cluster with in-cluster failover if we're
not using HADR?
I'm afraid I'd be beyond my depth to try and give details of this.
Some info and further references here:
http://publib.boulder.ibm.com/infoce...n/c0006354.htm
Can the driver use DNS with multiple A records (one pointing to the primary and
the other to the alternate location?).

Not sure about that either, but I can try to find out. My speculation
is that one would not want to use DNS to try and access one or the
other because you may have to deal with unexpected errors such as
"sorry, can't connect to an HADR standby" because DNS doesn't have a
clue that it shouldn't route you to the standby.

Also, if the name shown in DNS is associated with multiple IP addresses
(if that's what you're referring to), and is also used in the HADR
configuration (HADR_*_HOST) it may cause trouble, since HADR requires
that the given host NOT be multi-homed and that its name is resolved to
match the configuration at both ends.

If you want I could pass your question on to someone who works on ACR
itself to see if they can better answer it.

Regards,
- Steve P.
--------------------------
Steve Pearson
IBM DB2 UDB for LUW Development
Portland, OR, USA

[Marc]

Hi Steve,

Please forward the question to someone who works on ACR.

The issue we're trying to resolve is the case where the first JDBC
client connection failed, how does the client know how to connect to
the 2nd HADR node?

From what I understand, if the first attempt to connect succeeds, then

the information on the 2nd HADR node is sent back to the client, so in
the event of a failure it will know where it needs to reroute for
failover. The issue has to do when trying to establish connectivity on
the first attempt (either the Node is unavailable, network issues,
etc).

Thanks,
Marc

[Steve Pearson (news only)]

Hi, Marc.

I think the question is changing underfoot. It originally had to do
with DNS.

Regarding rerouting with JDBC on first connection attempts, please see
the links I posted earlier. The JDBC universal driver can be
configured with alternate server information *at the client* which
allows reroute on a first connection attempt. If the server also has
an ACR alternate server configured (which applies to all client types),
then after a successful connection, the server configured info will be
sent back to the client (per usual) and will replace the client's
initial rerouting info.

Regards,
- Steve P.
--------------------------
Steve Pearson
IBM DB2 UDB for LUW Development
Portland, OR, USA

[Marc]

Thanks Steve.

I found the information I was looking for (configuring the client for
rerouting on a first connection attempt). I was hoping this would have
been possible without having to do any code changes (i.e. using Java
system properties or in the JDBC connection string somehow). It seems
the only way of doing this is by using JNDI and creating a serializable
Java Bean with the following 2 properties:
- alternateServerName
- alternatePortNumber..

Thanks,
Marc