We are thinking of starting to use clustering with our DB2 V8. I
understand that with clustering when a node goes down that the other
nodes will keep the database up for the users. What I would like to
know is does this include if the node has a hard drive crash and the
disks are not salvagable or just if the machine looses connection?
And if a new machine is used to replace the damaged one how does it
sync together? Any information on the subject will be appreciated.

Daniel G. Cantua
Los Angeles County - ISD

Daniel,

Have you downloaded DB2 Stinger? Given that you are just "starting to
look" you want to add HADR to your choices. Take peek :-)

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

Cluster-based high availability tends to work by combining multi-ported disk
devices,
spare processing power, and a cluster manager (such as HACMP, MSCS, etc.).
When
a processor fails, the services that were running there (which could include
a DB2 "node"
aka processing "partition") are restarted in the spare processing facilities
(which may have
previously been idle, or may be already loaded processors that are set up to
absorb
additional workload in a failover). The disk resources associated with the
failed node
need to be accessible from the new node as well.

Disk (media) recovery is not usually part of this picture. Other approaches
are used
for that, including RAID/mirroring and database recovery (restore and
rollforward).

HADR (high availability disaster recovery), mentioned by Serge, is a log
shipping
database replication feature. Such products are typically deployed to
provide
failover to both different processors and different disks. This can be used
within
a cluster, with *separate* disk resources, which is different from the usual
configuration
meant when someone refers to cluster-based HA. More typically, log shipping
based HA is deployed between independent (not clustered) systems, either
within
one data center for "local" failover, or between geographically separated
("remote")
systems for protection against whole site failures.

Regards,
-steve p.
-------------------
Steve Pearson
DB2 UDB Development
Portland, OR, USA


"Daniel G. Cantua" <dcantua@co.la.ca.us> wrote in message
news:6cca870b.0405140838.582de62d@posting.google.c om...[color=blue]
> We are thinking of starting to use clustering with our DB2 V8. I
> understand that with clustering when a node goes down that the other
> nodes will keep the database up for the users. What I would like to
> know is does this include if the node has a hard drive crash and the
> disks are not salvagable or just if the machine looses connection?
> And if a new machine is used to replace the damaged one how does it
> sync together? Any information on the subject will be appreciated.
>
> Daniel G. Cantua
> Los Angeles County - ISD[/color]

Steve,

If we use HADR on two machines and one the machines is physical
damaged or turned off, will the user be able to continue to work as if
nothing happen. Or will they have to do some type of reconfiguration
the the workstation. What we have are six sites in LA county that
will need to connect to this DB. We were thing that clustering will
take care of a disaster occurs. But it sounds like if we have two
machines using HADR that both machines will mirror each other. Can
this be used also for load balancing. Like I said I am new to this.

Thank You For Your Help,
Daniel G. Cantua
Los Angeles County - ISD

When the primary crashes and DB2 fails over to the secondary, the user
will have to reconnect. The secondary will assume the IP address of the
primary, so the user will just reconnect to the same database on the
same instance (it will seem the same to the application).

When DB2 Stinger ships, the reconnection will not be necessary.

Daniel G. Cantua wrote:
[color=blue]
> Steve,
>
> If we use HADR on two machines and one the machines is physical
> damaged or turned off, will the user be able to continue to work as if
> nothing happen. Or will they have to do some type of reconfiguration
> the the workstation. What we have are six sites in LA county that
> will need to connect to this DB. We were thing that clustering will
> take care of a disaster occurs. But it sounds like if we have two
> machines using HADR that both machines will mirror each other. Can
> this be used also for load balancing. Like I said I am new to this.
>
> Thank You For Your Help,
> Daniel G. Cantua
> Los Angeles County - ISD[/color]

> If we use HADR on two machines and one the machines is physical[color=blue]
> damaged or turned off, will the user be able to continue to work as if
> nothing happen. Or will they have to do some type of reconfiguration
> the the workstation. What we have are six sites in LA county that
> will need to connect to this DB. We were thing that clustering will
> take care of a disaster occurs. But it sounds like if we have two
> machines using HADR that both machines will mirror each other.[/color]

The results from the user's perspective would depend on specifics of the
configuration and application. First, something or somebody (cluster
manager software, a system administrator, etc.) must recognize that a
failure has occurred and invoke the TAKEOVER HADR command.
Once the standby takes over as new primary, the applications will need
to reconnect. How exactly this happens depends somewhat on the
application's own behavior. As Blair mentioned, in Stinger there
will also be an ability to configure an automatic connection rerouting.
In-flight transactions must roll back, but the client can be reconnected
to the alternative server automatically. Other possible elements of
the failover, such as moving IP addresses around and so on are out of
HADR's control but may come into play with how the application
behaves. HADR only makes the standby database available at the
standby site after issuance of a Takeover command.

Traditional in-cluster failover (not involving HADR) is another
alternative, as I discussed before.

[color=blue]
> Can this be used also for load balancing.[/color]

In the Stinger release, HADR does not provide for anything like this.
What is most common with log-shipping database replication products
(in which category HADR falls) is to provide for periodic consistent
read access and/or periodic or continuous dirty read access to data
at the standby site. We recognize the value of this kind of access, and
it is high on our list of possible future enhancements to HADR.

Other kinds of replication technologies, such as DB2 SQL Replication
or, coming with Stinger, MQ Series based "Q" Replication, provide
logical (vs. HADR's physical) replication, at object rather than database
level, and the possibility of load balancing through either multi way
replication (update anywhere) or consistent read on non-updated sites.
Such features can also be employed in support of high availability, but
with somewhat different failover characteristics.

So you have plenty of choices! :-)

Regards,
-steve p.
-------------------
Steve Pearson
DB2 UDB Development
Portland, OR, USA