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.
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.
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.
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.
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.