DB2 Version 9.7 for Linux, UNIX, and Windows

High Availability Disaster Recovery (HADR)

The DB2® Data Server High Availability Disaster Recovery (HADR) feature is a database replication feature that provides a high availability solution for both partial and complete site failures. HADR protects against data loss by replicating data changes from a source database, called the primary, to a target database, called the standby.

HADR might be your best option if most or all of your database requires protection, or if you perform DDL operations that must be automatically replicated on the standby database.

Unless you have reads on standby enabled, applications can access the current primary database only. If you have reads on standby enabled, only write applications can access the current primary database, but read applications can access both the primary and the active standby. This enables you to offload some of the read-only workload running on the primary to the standby. Applications connecting to the standby database do not affect the standby's availability in case of a failover.

The standby database is kept in synch with the primary database through log data that is generated on the primary and shipped to the standby. The standby constantly rolls forward through the logs.

A partial site failure can be caused by a hardware, network, or software (DB2 database system or operating system) failure. Without HADR, a partial site failure requires restarting the database management system (DBMS) server that contains the database. The length of time it takes to restart the database and the server where it resides is unpredictable. It can take several minutes before the database is brought back to a consistent state and made available. With HADR, the standby database can take over in seconds. Further, you can redirect the clients that were using the original primary database to the standby database (new primary database) by using automatic client reroute or retry logic in the application.

A complete site failure can occur when a disaster, such as a fire, causes the entire site to be destroyed. Because HADR uses TCP/IP for communication between the primary and standby databases, they can be situated in different locations. For example, your primary database might be located at your head office in one city, while your standby database is located at your sales office in another city. If a disaster occurs at the primary site, data availability is maintained by having the remote standby database take over as the primary database with full DB2 functionality. After a takeover operation occurs, you can bring the original primary database back up and return it to its primary database status; this is known as failback.

After the failed original primary server is repaired, it can rejoin the HADR pair as a standby database if the two copies of the database can be made consistent. After the original primary database is reintegrated into the HADR pair as the standby database, you can switch the roles of the databases to enable the original primary database to once again be the primary database.

With HADR, you can choose the level of protection you want from potential loss of data; more specifically, you choose which side of the trade off between high availability and disaster recovery you want to favor. A typical setup that values protection more will likely employ a more synchronous synch mode and a longer peer window duration, whereas a setup that values availability more will likely use a more asynchronous sync mode and a shorter peer window.

HADR is only one of several replication solutions offered in the DB2 product family. InfoSphere® Federation Server and the DB2 database system include SQL replication and Q replication solutions that can also be used, in some configurations, to provide high availability. These functions maintain logically consistent copies of database tables at multiple locations. In addition, they provide flexibility and complex functionality such as support for column and row filtering, data transformation, updates to any copy of a table, and they can be used in partitioned database environments.

For setting up HADR, you can use the task assistant available in IBM® Data Studio Version 3.1 or later. Task assistants can guide you through the process of setting options, reviewing the automatically generated commands to perform the task, and running these commands. For more details, see Administering databases with task assistants.