DB2 10新特性: HADR新特性介绍

在刚刚发布的 DB2 LUW 10.1 中，高可用性灾难恢复 HADR 增加了一些新的特性，即对于多个备机数据库的支持、日志假脱机、延时重做。通过配置多个备机，用户可以同时实现高可用性和灾难恢复的目标，即在同城配置拥有较强同步模式的主要备机实现高可用性，又在距

使用日志假脱机，在主机交易高峰期，减少因为备机重做较慢而对主机业务产生的影响。延迟重做则使用户通过 HADR 可以撤回一些误操作。

HADR 基础

HADR（High Availability Disaster and Recovery）是 DB2 Linux Unix and Windows 中高可用性和灾难恢复的解决方案。通过该解决方案，用户可以为实际生产系统的设置一个备用，前者称为主数据库（Primary Database），后者称为备机数据库（Standby Database）。主数据库上的数据更改通过数据库日志（Log）传送到备机数据库上，备机数据库通过重做（Replay）这些日志完成与主数据库上相同的数据更改，从而使二者的数据保持一致。在主数据库发生故障时，用户可以在备机数据库上通过接管 HADR（TAKEOVER HADR）命令使备机数据库成为新主数据库，业务应用可以运行在新主数据库之上，从而使数据库服务恢复。

HADR 接管

备机数据库接管主数据库有两种方式，一种是强制接管（TAKEOVER HADR BY FORCE），另一种是非强制接管（non-force TAKEOVER，即不带 BY FORCE 的 TAKEOVER HADR 命令）。强制接管用于原主数据库不可用的情况下，备机数据库接管数据库服务；非强制接管用于系统在线升级（rolling upgrade）。

HADR 同步模式

主数据库和备机数据库之间的日志传输通过 HADR 同步模式（HADR_SYNCMODE）这一数据库配置参数控制。目前，有四种同步模式可供选择，按照同步程度从强到弱依次是：

同步模式（SYNC）

在同步模式下，当用户在主数据库上提交一个事务时，首先该事务的相关数据库日志会被写到主数据库的本地磁盘上，然后主数据库会将日志发送给备机数据库，并且等待备机数据库的回复；备机数据库在接收到日志，并将其写到自己的磁盘上后，才回复给主数据库。主数据库在接到备机数据库的回复之后，才返回给用户该事务提交成功。由此可见，在该同步模式下，凡是提交成功的事务，日志不仅在主数据库的磁盘上，也在备机数据库的磁盘上，此时如果主数据库发生故障，已提交的数据不会丢失。因此，在同步模式下，HADR 能够提供无数据丢失保证（No data loss guarantee）。但是，在该同步模式下，HADR 对主数据库业务的影响也是显而易见的。

近同步模式（NEARSYNC）

与同步模式相比，近同步模式下的备机数据库接收到主数据库发来的日志时，并不等待将其写到本地磁盘之后才回复给主数据库，而是立即回复给主数据库。主数据库在接收到备机数据库的回复之后就返回给用户事务提交成功，而此时，该事务的日志可能还在备机数据库的内存中，并未写到本地盘上。如果此时主机发生故障，并不能保证在原主数据库上已提交的数据在备机上必然能找回。虽然该同步模式不能保证零数据丢失，但是相比同步模式，近同步模式下的 HADR 对于主数据库业务的影响较小。

异步模式（ASYNC）

在异步模式下，主数据库发送日志成功后就返回给用户，事务提交成功，而此时，备机数据库有可能还没有收到这些日志。如果此时主数据库发生故障，该已提交事务的数据更改就会丢失。同样的，由于异步模式下的主数据库在返回给用户事务提交成功之前不等待备机数据库的回复，HADR 对主数据库上业务的影响比近同步模式更小。

超级异步模式（SUPERASYNC）

从 DB2 LUW V9.7.5 和 V9.5.8 开始，HADR 引入了一种新的同步模式，即超同步模式。在该同步模式下，主数据库上数据库日志的产生与发送完全分离，二者没有任何依赖，这样 HADR 对于主数据库业务的影响降到了最低；同时，由于日志的产生与发送分离，可能导致主数据库和备机数据库之间的差距较大，此时如果主机发生故障，会有较多的数据丢失；并且非强制接管（non-force TAKEOVER）可能需要更多时间。

以上四种同步模式，同步强度从强到弱，无数据丢失保证从高到低。有关同步模式的更详细描述，请参考本文末尾参考资源中的“DB2 HADR 监控详解”一文。

HADR 的备机可读

备机数据库通过重做（Replay）主数据库发送的数据库日志（Transaction Log）来完与主数据库上完全一致的数据更改，这一重做过程是通过数据库前滚（Database Rollforward）来实现的。在 V9.7 Fix Pack 1 之前，备机数据库只进行日志的重做，用户不能进行任何读写数据的操作，因此备机数据库对于用户来说是不可用的。从 V9.7 Fix Pack 1，DB2 引入了备机数据库可读的特性，用户可以将只读应用运行在备机数据库上，从而提高系统的利用率以及降低主数据库的负载。关于 HADR 的备机可读特性，请参考本文参考资源中的“DB2 V9.7 高可用性灾难恢复中的备机可读”一文。

DB2 HADR 近几个版本稳定性不断提高，功能上虽然有一些改进，例如 V9.5 增加了 peer window 和集成的 HA 方案；V9.7 增加了备机可读（RoS），但是一直没有大幅度的改动。DB2 V9.8 增加了 DB2 purescale 特性，但是该版本不支持 HADR。

DB2 LUW V10.1 中，HADR 是几个版本以来改动最大的一次，在这个版本中，主要有以下几方面新的功能。

多点灾备（HADR Multiple Standby）

一个主机可以支持多台备机（最多 3 台）。在该版本以前，HADR 的一台主机只能有一台备机。如果客户有多点灾备的需求，只能通过 Q 复制和 SQL 复制等方式实现。这些方式虽然在某种方面上有其优势，但是实时性和易用性都不如 HADR，而且，多种灾备方式要求 DBA 掌握更多的知识进行维护，也就增加了维护的成本。有了这个特性，客户就可以使用 HADR 进行统一的高可用性和灾备部署。一种典型的部署是：本地使用 HADR 做实时热备，一个远程使用异步方式（以免对本地事务造成压力）进行数据库同步，另一个远程同样使用异步方式同步，但是可以使用重演延迟防止错误操作。

日志假脱机（Log Spooling）

可以想象，任何一种同步方式都是将数据从一端发往另一端。HADR 也不例外，主机会根据不同的配置以不同的方式将日志发送给备机进行同步。这样就必不可少的增加了网络上的开销。很多客户为了节省开销，会使用性能稍差的备机。正常的交易下，备机还没有什么压力，但是交易高峰期间，备机可能跟不上主机的压力，使得接收日志的内存缓冲区变满，从而在某些同步模式下影响了主机的性能。为了解决这个问题，V10.1 中增加了该功能。当内存中没有空间接收日志时，就将日志写到磁盘上。当主机压力降下来以后，再将这些事务进行重做。这样，即使交易高峰期间，也不会对主机性能造成影响。而且日志保存在了备机上，即使主机出现故障停机，也不会在备机上丢失数据。

重演延迟（Delay Replay）

顾名思义，这个功能是让备机延时重做主机上的事务。为什么要这样做呢？试想一下，DBA 不小心错误的删除了数据库中的一张表。在没有这个功能之前怎么办呢？我们只使用某个时间的备份文件，将主机上的数据恢复到删除表以前，然后再前滚到刚好删除删除表的那个时间点。然后还要重新初始化 HADR 的备机。而这个时间段上，服务是停掉的。对于大型的数据库来说，无疑是一种很大的挑战。如果是使能了这个功能，事情就变得简单多了。因为虽然主机上错误的删除了这个表，但是备机并没有执行这个操作。客户只要停掉备机上的 HADR，然后前滚到删除表的那个时间点以前就可以了。当然，初始化 HADR 还是需要的。

更详细的监控

DB2 LUW v10 中对 HADR 的监控内容更加详细。例如可以看到主机和备机上的事务的时间，可以看出来接收的日志的位置和重做的日志的位置，可以分析出来 HADR 在网络上的开销等等。