DB2 10.5 for Linux, UNIX, and Windows

High availability disaster recovery (HADR)

High availability disaster recovery (HADR) 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 database, to the target databases, called the standby databases. HADR supports up to three remote standby servers.

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 that it takes to restart the database and the server where it is located is unpredictable. It can take several minutes before the database is brought back to a consistent state and made available. With HADR, a standby database can take over in seconds. Further, you can redirect the clients that used the original primary database to the 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. However, because HADR uses TCP/IP for communication between the primary and standby databases, they can be situated in different locations. For example, the primary database might be located at your head office in one city, and a standby database might be 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. You can initiate a failback if you can make the old primary database consistent with the new primary database. After you reintegrate the old primary database into the HADR setup as a 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 base the level of protection from potential loss of data on your configuration and topology choices. Some of the key choices that you must make are as follows:

What level of synchronization will you use?: Standby databases are synchronized with the primary database through log data that is generated on the primary and shipped to the standbys. The standbys constantly roll forward through the logs. You can choose from four different synchronization modes. In order of most to least protection, these are SYNC, NEARSYNC, ASYNC, and SUPERASYNC.
Will you use a peer window?: The peer window feature specifies that the primary and standby databases are to behave as though they are still in peer state for a configured amount of time if the primary loses the HADR connection in peer state. If primary fails in peer or this "disconnected peer" state, the failover to standby occurs with zero data loss. This feature provides the greatest protection.
How many standbys will you deploy?: With HADR, you can use up to three standby databases. With multiple standbys, you can achieve both your high availability and disaster recovery objectives with a single technology. For more information, see HADR multiple standby databases.
Do you want to combine HADR with DB2 pureScale®: The DB2 pureScale feature offers outstanding availability and scalability and can now be combined with HADR to meet both your high availability and disaster recovery needs. For more information, see High availability disaster recovery (HADR) in DB2 pureScale environments.

There are a number of ways that you can use your HADR standby or standbys beyond their HA or DR purpose:

Reads on standby: You can use the reads on standby feature to direct read-only workload to one or more standby databases without affecting the HA or DR responsibility of the standby. This feature can help reduce the workload on the primary without affecting the main responsibility of the standby.
Unless you have reads on standby enabled, applications can access the current primary database only. If you have reads on standby enabled, read-only applications can be redirected to the standby. Applications connecting to the standby database do not affect the availability of the standby in the case of a failover.
Delayed replay: You can use delayed replay to specify that a standby database is to remain at an earlier point in time than the primary, in terms of log replay. If data is lost or corrupted on the primary, you can recovery this data on the time delayed standby.
Rolling updates and upgrades: Using an HADR setup, you can make various types of upgrades and DB2 fix pack updates to your databases without an outage. If you are using multiple standby databases, you can perform an upgrade while at the same time keeping the protection provided by HADR. For more information, see Performing rolling updates in a DB2 high availability disaster recovery (HADR) environment.

Table 1 contains an overview of what HADR functionality is supported by each type of HADR setup.

Table 1. Supported HADR functionality for different deployments
Functionality or feature	Principal standby	Auxiliary standby	Principal standby in a DB2 pureScale environment
Synchronization mode	All modes are supported	ASYNC and SUPERASYNC modes only	SUPERASYNC only
Reads on standby	Supported	Supported	Not supported
Delayed replay	Supported	Supported	Supported
Log spooling	Supported	Supported	Supported
Tivoli SA MP as cluster manager for automated failover to HADR standby	Supported	Not supported	Not supported
Peer window	Supported	Not supported	Not supported
Network address translation (NAT)	Supported	Supported	Not supported
Automatic client reroute (ACR)	Supported	Supported	Supported
Client affinitiesClient affinities (see "Client affinities for clients that connect to DB2 for Linux, UNIX, and Windows" in "Call Level Interface Guide and Reference".	N/A	N/A	Supported

HADR might be your best option if most or all data in your database requires protection or if you perform DDL operations that must be automatically replicated on a standby database. However, HADR is only one of several replication solutions that are offered in the DB2 product family. The InfoSphere® Federation Server software and the DB2 database system include SQL replication and Q replication solutions that you can also use, in some configurations, to provide high availability. These solutions 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, and updates to any copy of a table. You can also use these solutions in partitioned database environments.

In IBM Data Studio Version 3.1 or later, you can use the task assistant for setting up HADR. 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.