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