High Availability Disaster Recovery (HADR)

High Availability Disaster Recovery (HADR) is a new feature introduced in DB2 UDB v8.2 for Linux, UNIX, and Windows. It is an integrated feature that provides for both high availability and disaster recovery by replicating data from a primary database to a standby database. HADR provides data protection for both partial system failures due to hardware or software failures and complete site failures due to natural disasters.

db2_udb_hadr

DB2 UDB also includes two new Wizards to configure and manage HADR that are accessed from the DB2 Control Center. These are:

  • Set Up High Availability Disaster Recovery (HADR) - This wizard is used to set up and configure primary and standby databases for high availability disaster recovery.
  • Manage High Availability Disaster Recovery - This wizard is used to optionally reconfigure, check the status, and provides alerts to any problems with the HADR configuration.

HADR replicates data from the primary to the standby database server via a mechanism commonly referred to as log buffer shipping. Log buffer shipping overcomes many of the limitations associated with traditional log shipping and data replication that can result in significant data loss. HADR can be configured to replicate database transaction logs buffers in one of three modes:

  • Synchronous (zero data loss) - In this mode the log buffer is written to storage at the standby database server before it is committed on the primary database server. The standby database server commits the log buffer data only after notification from the primary database server that that the log buffer has been committed. The primary database server will not proceed to flush the next log buffer until receives notification that the standby database server has committed the log buffer as well. Ultimately, the transaction is committed when the log buffer data has been written to storage at both the primary and at standby servers, thus ensuring zero data loss.
  • Near Synchronous - In this mode the log buffer data is guaranteed to be successfully sent to the standby database server, but it is not required to be written to storage before the commit on the primary database server succeeds. The log buffer write at the primary database server and the transfer of the log buffer to the standby database server are performed in parallel. In this mode a commit succeeds only when the log buffer data is written to storage at the primary and the log buffer data has been received by the standby server. This mode has the potential for data loss in the unlikely event that there is a simultaneous failure at both the primary and standby database server.
  • Asynchronous - In this mode the log buffer is not guaranteed to be received by the standby database server, but only that the log data buffer has been passed to the TCP/IP stack and that the socket send call was successful. In this mode the log buffer data is written at the primary database server and the sent to the standby database server in parallel. The log buffer data is committed once it has been written to storage at the primary database server and sent to the standby database server. This mode has the potential for data loss, but only in the event that the TCP/IP packets are not received by the standby database server. TCP/IP sockets do guarantee delivery order and as long as the sockets stay alive there will never be any missing or out of order packets.

HADR function is available as part of the DB2 UDB Enterprise Server Edition at no extra charge. Users of DB2 UDB Express and Workgroup Server Editions can add the HADR capability to their servers by purchasing the optional DB2 UDB High Availability Disaster Recovery license.

It is also possible to combine both clustering for localized high availability and HADR for remote disaster recovery

Notices

Copyright © 1998 - 2016 Ten Digit Consulting, LLC | All rights Reserved.