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
> Steve thanks for the quick response.
>
[quoted text clipped - 11 lines]
> 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).
> 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/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.
udb.doc/admin/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 - 07 Feb 2006 21:14 GMT
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) - 08 Feb 2006 17:30 GMT
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 - 22 Feb 2006 14:19 GMT
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