DB2 10 新特性: HADR 新特性介绍
HADR 基础HADR（High Availability Disaster and Recovery）是 DB2 Linux Unix and Windows 中高可用性和灾难恢复的解决方案。通过该解决方案，用户可以为实际生产系统的数据库设置一个备用数据库，前者称为主数据库（Primary Database），后者称为备机数据库（Standby Database）。主数据... 显示全部
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 在网络上的开销等等。
下面，将对这四个方面进行更详细的介绍。
HADR 的多备机
在介绍多备机特性之前，先从该特性的背景和需求开始说起。
为什么需要多备机
HADR 多备机（HADR Multiple Standby）的提出与高可用性（High Availability）和灾难恢复（Disaster Recovery）的不同需求密切相关。通常来说，高可用性的目标是在主数据库出现故障时，备机数据库能够在尽可能短的时间内接管，从而尽可能减少主数据库故障对业务系统的影响，这要求主数据库和备机数据库之间的距离不能很远。也就是说，在主数据库出现故障甚至宕机时，备机数据库能够迅速接管主数据库，业务系统中连接到原主数据库上的应用程序能够在短时间内连接到新的主数据库上，进而应用程序并不会受到原主数据库系统的故障影响。如果接管时间非常短，那么接管过程可能对业务系统来说会是透明的。从此需求出发，可以看出高可用性对同步模式的要求较高，通常为同步或者近同步模式。但是由于在较强的同步模式（例如同步和近同步）下，主数据库在返回给用户之前需要等待备机数据库的确认，网络传输日志的延迟会对主数据库上的业务产生明显的影响。为了减少日志网络传输对主数据库业务的影响，主数据库和备机数据库在地理位置上应部署在相距不远的两个数据站点，或者同一个数据站点中；同时，考虑到在备机数据库接管主数据库之后，原先连接到原主数据库上的应用程序，将会连接到新的主数据库（也就是原备机数据库），为了减小应用程序与数据库的通信开销，应用程序应该离主数据库和备机数据库都很近，即，主数据库和备机数据库地理位置上应该很近。
从灾难恢复（即灾备）考虑的出发，又要求主数据库和备机数据库之间的距离尽可能的远。灾难恢复，顾名思义，是在主数据库所在的数据站点发生了诸如地震、海啸、火灾等此类灾难后，主数据库的整个数据站点都被摧毁的情况下，备机数据库能够恢复出主数据库上的数据。由于这类灾难影响的范围通常来说比较广，在灾难发生时，主数据库所在的城市或者地区都可能受到灾难影响，如果备机数据库位于主数据库附近，势必也将受到影响，因此，从灾难恢复的角度出发，主数据库和备机数据库的距离应该尽可能的远，它们之间的距离通常是数千公里。
现有解决方案
在 DB2 LUW 10.1 发布之前，源生的 HADR 只支持一个备机数据库，应此要同时达到高可用性和灾难恢复这两个目标，只能借助于另外一个产品—— IBM InfoSphere Q-Replication（下文简称 QRep）。如图 1 所示，在同城使用 DB2 HADR 实现高可用性，在异地远程通过 QRep 提供灾难恢复支持。
图 1. 多备机的已有解决方案
实用 HADR 和 Q-Rep 同时实现高可用性和灾备需求
多备机特性
然而 HADR 和 Q-Rep 的组合，毕竟没有 DB2 源生多备机支持配置和使用起来方便，因此，在 DB2 LUW V10.1 中，HADR 对于多备机（Multiple Standby）提供了源生支持，用户只需进行简单的配置，即可用 HADR 不同的备机数据库同时实现高可用性和灾难恢复的需求，如图 2 所示：在多备机数据库的配置下，可以指定一个主要备机（Principal Standby）实现高可用性目标，另外两个辅助备机（Auxiliary Standby）提供灾难恢复支持。
图 2. HADR 中的源生多备机解决方案
HADR 的多备机
在 HADR 多备机这一新的特性中，备机数据库被分为两类，一类是主要备机（Principal Standby），另一类是辅助备机（Auxiliary Standby）。两者的区别在于和主数据库的同步模式不同，主要备机可以使用任何同步模式接受主数据库事务日志，即同步、近同步、异步、超级异步中的一种，而辅助备机只能使用超级异步模式来接受主数据事务日志。主要备机的同步模式是通过配置主数据库上的 HADR 同步模式（HADR_SYNCMODE）这一数据库配置参数来实现的，由于辅助备机的同步模式只能为超级异步模式，因此无需配置。从二者同步模式的差异以及对高可用性和灾难恢复的不同需求可以看出，主要备机是为高可用性的需求设计的，而辅助备机则是以灾难恢复为目标的。
在 HADR 多备机的配置下，最多可配置三个备机，一个主要备机和两个辅助备机，主要备机是必须的，辅助备机是可选的。在所有的备机上，包括主要备机和辅助备机，都支持备机可读（Reads On Standby），并且可以进行强制和非强制接管（TAKEOVER HADR BY FORCE 和不带 BY FORCE 的 TAKEOVER HADR）。
为了配置 HADR 的多备机，在 DB2 LUW V10.1 中引入了一个新的数据库配置参数—— HADR_TARGET_LIST，顾名思义，该参数是用来指定备机列表的。该参数的语法是：
清单 1. HADR_TARGET_LIST 的语法
UPDATE DATABASE CONFIGURATION FOR dbname USING
HADR_TARGET_LIST host1:port1|host2:port2|host3:port3
在主数据库上的该参数，是用来指定备机数据库列表的，列表中的第一个备机数据库就是主要备机，其余的备机数据库是辅助备机。在备机数据库上，该参数定义了在该备机接管之后的备机数据库列表，列表中的第一个数据库将成为该备机接管之后的主要备机，其他数据库将成为辅助备机。与以往的 HADR 数据库配置参数不同，该参数不要求主数据库与备机数据库相同，也不要求主要备机和辅助备机之间相同。同时，该参数是动态生效的，也就是说，修改该参数并不要求重启数据库。对主数据库来说，这一点尤为重要，用户可以在完全不影响主数据库上业务的情况下，修改 HADR 的备机配置。用户可以动态的添加、删除一个辅助备机，该添加和删除操作在 HADR_TARGET_LIST 参数修改时即刻生效，甚至无需重启 HADR，仅在修改主要备机时，需要重新启动 HADR。该参数也是多备机特性的开关，在主数据库配置了该参数之后，即使在备机列表中只配置一个备机，主机也会运行在多备机的模式下。
运行在 HADR 多备机模式下的主数据库和备机数据库，与单一备机数据库配置下的主数据库和备机数据库行为上有一些差异。在单一备机的配置下，HADR 要求主数据库和备机数据库上同步模式（HADR_SYNCMODE）、HADR 超时（HADR_TIMEOUT）、HADR 对等窗口（HADR_PEER_WINDOW）等的配置完全相同，否则 HADR 将不能启动。在 HADR 多备机配置下，主数据库上的这些参数将决定主数据库与主要备机之间的配置，而备机数据库（包括主要备机和辅助备机）上的这些参数，则是用来定义在该备机接管之后与主要备机之间的配置。因此，备机数据库上的这些参数只有在该备机接管之后才真正有意义，在备机状态下它们并没有生效。
HADR 多备机的使用示例
接下来，用一个简单的例子介绍如何使用 HADR 多备机这一新特性。假设有 4 台数据库服务器，分别是 host1/host2/host3/host4，其中 host1 将配置为主数据库，host2 将配置为主要备机数据库，host3 和 host4 将配置为辅助备机数据库，数据库名为 MYDB，数据库实例（Instance）名为 inst1。
第一步，备份主数据库：
清单 2. 备份主数据库
# 在 host1 上：
db2 BACKUP DB MYDB
Backup successful. The timestamp for this backup image is : 20120503013434
第二步，在备机上还原数据库：
清单 3. 还原数据库
# 将备份镜像分别复制到 HOST2、HOST3 上，然后分别还原数据库
db2 RESTORE DB MYDB
DB20000I The RESTORE DATABASE command completed successfully.
第三步，配置主数据库：
清单 4. 配置主数据库
# 在 host1 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522
HADR_REMOTE_HOST host2
HADR_REMOTE_SVC 41520
HADR_SYNCMODE sync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host1
HADR_LOCAL_SVC 41518"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
第四步，配置主要备机：
清单 5. 配置主要备机
# 在 host2 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host1:41518|host3:41522
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_LOCAL_HOST host2
HADR_LOCAL_SVC 41520
HADR_SYNCMODE sync
HADR_REMOTE_INST inst1"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
第五步，配置辅助备机：
清单 6. 配置辅助备机
# 在 host3 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host1:41518
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_SYNCMODE superasync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host3
HADR_LOCAL_SVC 41522"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
备机上的这些参数，将在该备机接管之后生效。备机数据库运行时使用的 HADR 配置参数来自于主数据库。
第六步，启动备机：
清单 7. 启动主要备机和辅助备机
# 在 host2 上
db2 START HADR ON DB MYDB AS STANDBY
DB20000I The START HADR ON DATABASE command completed successfully.
# 在 host3 上
db2 START HADR ON DB MYDB AS STANDBY
DB20000I The START HADR ON DATABASE command completed successfully.
第七步，启动主数据库：
清单 8. 启动主数据库上的 HADR
# 在 host1 上
db2 START HADR ON DB MYDB AS PRIMARY
DB20000I The START HADR ON DATABASE command completed successfully.
第八步，检查状态，验证 HADR 状态：
清单 9. 验证 HADR 状态
# 在 host1 上
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host1.ibm.com host2.ibm.com
PRIMARY 2 REMOTE_CATCHUP host1.ibm.com host3.ibm.com
2 record(s) selected.
这里在验证 HADR 运行状态的时候，用到了监视器函数 MON_GET_HADR，该函数是 DB2 LUW V10.1 新引入的、用来返回 HADR 实时情况的表函数，DB2 同时还提供了新的 db2pd 的命令行接口。关于这两个监视工具的详细使用方法以及返回内容的具体含义，请参考本文末尾参考资源中的 DB2 信息中心。
至此，一个完整的 HADR 多备机环境已经配置完成。
刚才已经提到，HADR 多备机新特性支持动态添加、删除辅助备机。清单 10 中演示了如何动态添加一个辅助备机：只需在新的辅助备机上从主数据库备份镜像中还原出主数据库，配置好 HADR 参数之后，将其启动为备机数据库；然后在主机上修改 HADR_TARGET_LIST 这一数据库参数，将该新辅助备机数据库服务器名和端口号添加到 HADR_TARGET_LIST 之中即可，该辅助备机将在 HADR_TARGET_LIST 参数修改完成后实时生效，无需重行启动主数据库上的 HADR 服务（STOP HADR 后 START HADR AS PRIMARY），更无需重启主数据库（DEACTIVATE DATABASE 后 ACTIVATE DATABASE）。
清单 10. 动态添加辅助备
# 在 host4 上
db2 RESTORE DB MYDB
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522|host1:41518
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_SYNCMODE supersync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host4
HADR_LOCAL_SVC 41524 "
db2 START HADR ON DB MYDB AS STANDBY
# 在 host1 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522|host4:41524"
除了同步模式之外，主要备机和辅助备机是相同的。它们都是在重做（Replay）主数据库方面传送过来的数据库事务日志，这一点与 HADR 单一备机下的备机数据库完全相同。因此，原先单一备机环境下备机数据库的所有特性，在多备机环境下的主要备机和辅助备机都支持。清单 11 列出了如何在主要备机上接管 HADR，清单 12 则列出了如何在辅助备机上接管 HADR，二者与单一备机下的备机数据库接管 HADR 完全相同。
清单 11. 主要备机接管 HADR
# 在 host2 上
db2 TAKEOVER HADR ON DB MY DB
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host2.ibm.com host1.ibm.com
PRIMARY 2 REMOTE_CATCHUP host2.ibm.com host3.ibm.com
PRIMARY 3 REMOTE_CATCHUP host2.ibm.com host4.ibm.com
3 record(s) selected.
清单 12. 辅助备机接管 HADR
# 在 host3 上
db2 TAKEOVER HADR ON DB MY DB
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host3.ibm.com host2.ibm.com
PRIMARY 2 REMOTE_CATCHUP host3.ibm.com host1.ibm.com
PRIMARY 3 REMOTE_CATCHUP host3.ibm.com host4.ibm.com
3 record(s) selected.
在接管之后，MON_GET_HADR 返回的 HADR 状态也会实时更新。
注意，在单点模式下，同步模式配置的规则和以前的版本没有区别。但是在多点模式下，主要备机的同步模式取决于主机的同步模式，而非自己的参数配置。而辅助备机的同步模式必须为超级异步模式，本数据库中的该配置会被忽略。举个例子，对于以下配置的四台机器。以为 host1 的主要备机是 host2,，所以，host2 的实际同步模式是近同步，而非自己配置的同步，如图三所示。
图 3. 实际同步模式取决于主机和备机角色
实际同步模式取决于主机和备机角色
备机配置中的同步模式会在接管以后起作用，例如实例中，host2 上发生 takeover 以后，就会变成以下的配置，如图 4 所示。
图 4. 接管后备机上的同步模式才起作用
接管后备机上的同步模式才起作用
日志假脱机（Log Spooling）
前面已经提到这个功能主要是为了缓解备机对主机造成的压力。它的作用和超级异步模式类似。但是超级异步模式下，如果备机重做的慢，主机上的日志就不能传到备机上。一旦发生事故需要接管，事务就会丢失。而日志假脱机是把日志保存在备机上，只是重做的时机不能和主机同步。即使接管，已经保存的事务也不会丢失，但是接管的时间可能会相对长一点。
为了使能这个功能，需要配置一个新的数据库参数 HADR_SPOOL_LIMIT。该参数制定了最多可以再硬盘上缓冲多少日志。它的单位是 4K。如果它的值是 0，代表没有使能该功能；如果它的值是 -1，代表缓冲区没有限制。
重演延迟（Delayed Replay）
该功能主要是为了在主机由错误操作的情况下，备机可以快速的恢复到误操作以前的数据。DB2 V10.1 中，增加了数据库配置参数 HADR_REPLAY_DELAY 对该功能进行配置。该参数制定了延时重做的时间。它以秒为单位，0 代表不打开该功能。如果日志的时间戳小于备机上当前的时间减去 HADR_REPLAY_DELAY 的值，就不去应用该日志。基于这个原理，主机和备机的时间同步是很重要的。
该功能只在 HADR 的备机上支持，如果主机配置了该参数，启动的时候就会报错。该功能只支持超级异步模式的备机，而且，使能了该功能的备机不支持接管。
如果用户使用了该功能，作者建议同时使能日志假脱机。这样，就会有尽可能多的日志保存在备机上，而使备机前滚到尽可能晚的位置。我们举一个反例，如果 HADR_REPLAY_DELAY 被设置成了两个小时，但是备机的接收缓存（内存和磁盘缓存的总和，即 HADR 内存接收缓存和 HADR_SPOOL_LIMIT 的总和）只能保存一个小时产生的日志。一旦主机发生意外停机，备机将不能恢复到一小时之后的位置，因为那些位置的日志没有传到备机上。
重演延迟示例
这里，作者通过以下的实例来展示一下改功能。为了能在备机上进行查询，作者在备机上打开了 RoS（Read on Standby），简单起见，作者使用的是单一备机模式。
清单 13. 备机上的设置
sfbao@skua:~>db2set
DB2_STANDBY_ISO=UR
DB2_HADR_ROS=1
接下来，我们设置一个 HADR 环境，然后更新配置：
清单 14. 重演延迟的数据库设置
# 备机上：
sfbao@skua:~>
db2 update db cfg for hadrdb using HADR_LOCAL_HOST skua HADR_REMOTE_HOST tern
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 update db cfg for hadrdb using HADR_SYNCMODE superasync
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 update db cfg for hadrdb using HADR_REPLAY_DELAY 600
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 start hadr on db hadrdb as standby
DB20000I The START HADR ON DATABASE command completed successfully.
# 主机上：
sfbao@tern:~>db2 update db cfg for hadrdb using hadr_syncmode superasync
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@tern:~>db2 start hadr on db hadrdb as primary
DB20000I The START HADR ON DATABASE command completed successfully.
通过 db2pd -hadr 查看一下状态：
清单 15. 检查 HADR 状态
sfbao@skua:~>db2pd -db hadrdb -hadr | grep HADR_STATE
HADR_STATE = REMOTE_CATCHUP
因为是 superasync mode，数据库一直处于 remote catchup 的状态。这个结果表明 HADR 启动成功。
接下来，我们在主机上创建一个表：
清单 16. 在主机上创建表
sfbao@tern:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
sfbao@tern:~>db2 "create table t(id int, name char(254))"
DB20000I The SQL command completed successfully.
然后我们到备机上查询一下：
清单 17. 连接备机失败
sfbao@skua:~>db2 connect to hadrdb
SQL1776N The command cannot be issued on an HADR standby database. Reason
code = "4".
备机返回错误，怎么回事？这是因为 ROS 的限制：当 DDL 在备机上重做的时候，备机不接收新的连接。从 db2pd -hadr 里面我们也可以看出来，这个时候，Replay Only Window 是活动的：
清单 18. 检查 HADR 的 Replay Only Window
sfbao@skua:~>db2pd -db hadrdb -hadr | grep REPLAY_ONLY_WINDOW
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = Y
STANDBY_REPLAY_ONLY_WINDOW_START = 04/16/2012 00:28:35.000000 (1334561315)
STANDBY_REPLAY_ONLY_WINDOW_TRAN_COUNT = 1
十分钟以后，我们重新连接到备机：
清单 19. DDL 重演被推迟
sfbao@skua:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
连接成功，说明这条 DDL 被延时了 10 分钟重做。我们在主机上插入一条数据，注意，我们这里使用了自动提交（Auto Commit）：
清单 20. 在主机上插入数据
sfbao@tern:~>db2 "insert into t values(1, 'hello')"
DB20000I The SQL command completed successfully.
然后在备机上查询一下：
清单 21. 检查备机上的数据
sfbao@skua:~>db2 "select * from t"
ID NAME
----------- --------------------------------------
1 hello
1 record(s) selected.
竟然查了出来，这又是怎么回事呢？这个是因为在 DB2 中，并不是每个日志记录都包含时间戳。一个打开自动提交的 insert 操作其实包含两部分的日志记录：insert 和 commit 的。当 insert 这部分传过来以后，这部分首先被重做了，所以可以从备机上查看到这个记录。但是实际上，这个操作并没有提交，也就是 commit 这部分并没有重做。这个时候，如果用一下的方式停掉备机上的 HADR，并且不进行前滚操作，就会得到以下结果：
清单 22. 停止 HADR 并检查备机上的数据
sfbao@skua:~>db2 deactivate db hadrdb
DB20000I The DEACTIVATE DATABASE command completed successfully.
sfbao@skua:~>db2 stop hadr on db hadrdb
DB20000I The STOP HADR ON DATABASE command completed successfully.
sfbao@skua:~>db2 rollforward db hadrdb complete
Rollforward Status
Input database alias = hadrdb
Number of members have returned status = 1
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000000.LOG - S0000000.LOG
Last committed transaction = 2012-04-16-08.12.25.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.
sfbao@skua:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
sfbao@skua:~>db2 "select * from t"
ID NAME
----------- --------------------------------------
0 record(s) selected.
这个结果表明，commit 语句其实在之前并没有被重做。
回页首
监控接口
DB2 V10.1 中 HADR 的监控内容更加丰富，用户可以从里面提取更多有用的信息。本文之前的部分，我们已经列出了一些监控的输出，其中有一些内容和以前的版本一致，请参考本文末尾的参考资源中“DB2 HADR 监控详解”一文。这里，我们不再进行说明，以下仅简单介绍监控输出的新内容：
REPLAY_TYPE，LOG_STREAM_ID 和 PRIMARY_MEMBER 的值目前为固定值，本文不对这几项进行解释；
STANDBY_ID：备机的编号，在多备机环境下，每台备机对于主机来说都有一个编号，这个编号从 1 开始；
PRIMARY_MEMBER_HOST：主数据库的主机名，相当于以前的 hadr_local_host；
STANDBY_MEMBER_HOST：备机数据库的主机名，相当于以前的 hadr_remote_host；
HADR_CONNECT_STATUS：当前的连接状态；
HADR_CONNECT_STATUS_TIME：HADR 变成当前连接状态的时间；
TIME_SINCE_LAST_RECV：网络上上一次收到数据的时间；
LOG_HADR_WAIT_CUR，LOG_HADR_WAIT_RECENT_AVG，LOG_HADR_WAIT_ACCUMULATED，LOG_HADR_WAIT_COUNT：从以上的参考资料中可以看出来，在同步、近同步、异步三种模式下，主机上的事务需要等待 HADR 将日志传输完成才可以提交，这四个参数是为了监控主机等待 HADR 传输日志用了多长时间，也就是 HADR 的开销。他们分别显示了当前的事务在 HADR 传输日志中等待的时间、最近几次等待时间的平均值、从 HADR 启动开始到当前时间内 HADR 传输日志总共用的时间、一共发生了多少次等待。因为每次传输日志都会等待，所以最后一个参数其实也代表了 HADR 一共传输过多少次日志或者说日志一共有多少次写操作；
PRIMARY_LOG_FILE, PAGE, POS：主机上最新的日志的位置；
STANDBY_LOG_FILE, PAGE, POS：备机上接收的最新的日志的位置；
STANDBY_REPLAY_LOG_FILE, PAGE, POS：备机重做的最晚的日志的位置。如果主机和备机的日志的位置差距大，表明日志不能即时传输；如果日志被重做的位置和备机接收的日志的位置差距大，表明备机重做的效率不高；
PRIMARY_LOG_TIME，STANDBY_LOG_TIME，STANDBY_REPLAY_LOG_TIME：分别表示主机上最新的日志的时间，备机接收的最新的日志的时间和备机重做的最新的日志的时间。
回页首
总结
DB2 LUW V10.1 在 HADR 方面的增强极大地提高了 DB2 的高可用性和灾备能力。考虑到高可用性（High Availability，HA）和灾难恢复（Disaster Recovery）本质上来说有着不同的业务需求：高可用性要求主数据库和备机数据库距离尽可能短，这样才能在主数据库出现故障时，备机数据库尽可能快地接管，从而缩短数据库服务中断的时间。而灾难恢复则希望主数据库在被地震、火灾等摧毁后，从备机还能恢复出主数据库中的数据。由于该类灾难影响的范围通常较大，所以从灾难恢复的角度出发，备机数据库与主数据库的距离应尽可能的远。二者矛盾的需求导致了不可能仅使用单个备机数据库来同时实现二者的要求，因此，新版本的 DB2 引入了 HADR 多备机的新特性，通过该特性，用户可以配置多于一个的备机数据库，轻松同时实现高可用性的目标以及提供灾难恢复的支持。同时，新版本的 DB2 对性能问题也有更好的处理，而且重演延迟这个功能还使得 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 在网络上的开销等等。
下面，将对这四个方面进行更详细的介绍。
HADR 的多备机
在介绍多备机特性之前，先从该特性的背景和需求开始说起。
为什么需要多备机
HADR 多备机（HADR Multiple Standby）的提出与高可用性（High Availability）和灾难恢复（Disaster Recovery）的不同需求密切相关。通常来说，高可用性的目标是在主数据库出现故障时，备机数据库能够在尽可能短的时间内接管，从而尽可能减少主数据库故障对业务系统的影响，这要求主数据库和备机数据库之间的距离不能很远。也就是说，在主数据库出现故障甚至宕机时，备机数据库能够迅速接管主数据库，业务系统中连接到原主数据库上的应用程序能够在短时间内连接到新的主数据库上，进而应用程序并不会受到原主数据库系统的故障影响。如果接管时间非常短，那么接管过程可能对业务系统来说会是透明的。从此需求出发，可以看出高可用性对同步模式的要求较高，通常为同步或者近同步模式。但是由于在较强的同步模式（例如同步和近同步）下，主数据库在返回给用户之前需要等待备机数据库的确认，网络传输日志的延迟会对主数据库上的业务产生明显的影响。为了减少日志网络传输对主数据库业务的影响，主数据库和备机数据库在地理位置上应部署在相距不远的两个数据站点，或者同一个数据站点中；同时，考虑到在备机数据库接管主数据库之后，原先连接到原主数据库上的应用程序，将会连接到新的主数据库（也就是原备机数据库），为了减小应用程序与数据库的通信开销，应用程序应该离主数据库和备机数据库都很近，即，主数据库和备机数据库地理位置上应该很近。
从灾难恢复（即灾备）考虑的出发，又要求主数据库和备机数据库之间的距离尽可能的远。灾难恢复，顾名思义，是在主数据库所在的数据站点发生了诸如地震、海啸、火灾等此类灾难后，主数据库的整个数据站点都被摧毁的情况下，备机数据库能够恢复出主数据库上的数据。由于这类灾难影响的范围通常来说比较广，在灾难发生时，主数据库所在的城市或者地区都可能受到灾难影响，如果备机数据库位于主数据库附近，势必也将受到影响，因此，从灾难恢复的角度出发，主数据库和备机数据库的距离应该尽可能的远，它们之间的距离通常是数千公里。
现有解决方案
在 DB2 LUW 10.1 发布之前，源生的 HADR 只支持一个备机数据库，应此要同时达到高可用性和灾难恢复这两个目标，只能借助于另外一个产品—— IBM InfoSphere Q-Replication（下文简称 QRep）。如图 1 所示，在同城使用 DB2 HADR 实现高可用性，在异地远程通过 QRep 提供灾难恢复支持。
图 1. 多备机的已有解决方案
实用 HADR 和 Q-Rep 同时实现高可用性和灾备需求
多备机特性
然而 HADR 和 Q-Rep 的组合，毕竟没有 DB2 源生多备机支持配置和使用起来方便，因此，在 DB2 LUW V10.1 中，HADR 对于多备机（Multiple Standby）提供了源生支持，用户只需进行简单的配置，即可用 HADR 不同的备机数据库同时实现高可用性和灾难恢复的需求，如图 2 所示：在多备机数据库的配置下，可以指定一个主要备机（Principal Standby）实现高可用性目标，另外两个辅助备机（Auxiliary Standby）提供灾难恢复支持。
图 2. HADR 中的源生多备机解决方案
HADR 的多备机
在 HADR 多备机这一新的特性中，备机数据库被分为两类，一类是主要备机（Principal Standby），另一类是辅助备机（Auxiliary Standby）。两者的区别在于和主数据库的同步模式不同，主要备机可以使用任何同步模式接受主数据库事务日志，即同步、近同步、异步、超级异步中的一种，而辅助备机只能使用超级异步模式来接受主数据事务日志。主要备机的同步模式是通过配置主数据库上的 HADR 同步模式（HADR_SYNCMODE）这一数据库配置参数来实现的，由于辅助备机的同步模式只能为超级异步模式，因此无需配置。从二者同步模式的差异以及对高可用性和灾难恢复的不同需求可以看出，主要备机是为高可用性的需求设计的，而辅助备机则是以灾难恢复为目标的。
在 HADR 多备机的配置下，最多可配置三个备机，一个主要备机和两个辅助备机，主要备机是必须的，辅助备机是可选的。在所有的备机上，包括主要备机和辅助备机，都支持备机可读（Reads On Standby），并且可以进行强制和非强制接管（TAKEOVER HADR BY FORCE 和不带 BY FORCE 的 TAKEOVER HADR）。
为了配置 HADR 的多备机，在 DB2 LUW V10.1 中引入了一个新的数据库配置参数—— HADR_TARGET_LIST，顾名思义，该参数是用来指定备机列表的。该参数的语法是：
清单 1. HADR_TARGET_LIST 的语法
UPDATE DATABASE CONFIGURATION FOR dbname USING
HADR_TARGET_LIST host1:port1|host2:port2|host3:port3
在主数据库上的该参数，是用来指定备机数据库列表的，列表中的第一个备机数据库就是主要备机，其余的备机数据库是辅助备机。在备机数据库上，该参数定义了在该备机接管之后的备机数据库列表，列表中的第一个数据库将成为该备机接管之后的主要备机，其他数据库将成为辅助备机。与以往的 HADR 数据库配置参数不同，该参数不要求主数据库与备机数据库相同，也不要求主要备机和辅助备机之间相同。同时，该参数是动态生效的，也就是说，修改该参数并不要求重启数据库。对主数据库来说，这一点尤为重要，用户可以在完全不影响主数据库上业务的情况下，修改 HADR 的备机配置。用户可以动态的添加、删除一个辅助备机，该添加和删除操作在 HADR_TARGET_LIST 参数修改时即刻生效，甚至无需重启 HADR，仅在修改主要备机时，需要重新启动 HADR。该参数也是多备机特性的开关，在主数据库配置了该参数之后，即使在备机列表中只配置一个备机，主机也会运行在多备机的模式下。
运行在 HADR 多备机模式下的主数据库和备机数据库，与单一备机数据库配置下的主数据库和备机数据库行为上有一些差异。在单一备机的配置下，HADR 要求主数据库和备机数据库上同步模式（HADR_SYNCMODE）、HADR 超时（HADR_TIMEOUT）、HADR 对等窗口（HADR_PEER_WINDOW）等的配置完全相同，否则 HADR 将不能启动。在 HADR 多备机配置下，主数据库上的这些参数将决定主数据库与主要备机之间的配置，而备机数据库（包括主要备机和辅助备机）上的这些参数，则是用来定义在该备机接管之后与主要备机之间的配置。因此，备机数据库上的这些参数只有在该备机接管之后才真正有意义，在备机状态下它们并没有生效。
HADR 多备机的使用示例
接下来，用一个简单的例子介绍如何使用 HADR 多备机这一新特性。假设有 4 台数据库服务器，分别是 host1/host2/host3/host4，其中 host1 将配置为主数据库，host2 将配置为主要备机数据库，host3 和 host4 将配置为辅助备机数据库，数据库名为 MYDB，数据库实例（Instance）名为 inst1。
第一步，备份主数据库：
清单 2. 备份主数据库
# 在 host1 上：
db2 BACKUP DB MYDB
Backup successful. The timestamp for this backup image is : 20120503013434
第二步，在备机上还原数据库：
清单 3. 还原数据库
# 将备份镜像分别复制到 HOST2、HOST3 上，然后分别还原数据库
db2 RESTORE DB MYDB
DB20000I The RESTORE DATABASE command completed successfully.
第三步，配置主数据库：
清单 4. 配置主数据库
# 在 host1 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522
HADR_REMOTE_HOST host2
HADR_REMOTE_SVC 41520
HADR_SYNCMODE sync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host1
HADR_LOCAL_SVC 41518"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
第四步，配置主要备机：
清单 5. 配置主要备机
# 在 host2 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host1:41518|host3:41522
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_LOCAL_HOST host2
HADR_LOCAL_SVC 41520
HADR_SYNCMODE sync
HADR_REMOTE_INST inst1"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
第五步，配置辅助备机：
清单 6. 配置辅助备机
# 在 host3 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host1:41518
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_SYNCMODE superasync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host3
HADR_LOCAL_SVC 41522"
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
备机上的这些参数，将在该备机接管之后生效。备机数据库运行时使用的 HADR 配置参数来自于主数据库。
第六步，启动备机：
清单 7. 启动主要备机和辅助备机
# 在 host2 上
db2 START HADR ON DB MYDB AS STANDBY
DB20000I The START HADR ON DATABASE command completed successfully.
# 在 host3 上
db2 START HADR ON DB MYDB AS STANDBY
DB20000I The START HADR ON DATABASE command completed successfully.
第七步，启动主数据库：
清单 8. 启动主数据库上的 HADR
# 在 host1 上
db2 START HADR ON DB MYDB AS PRIMARY
DB20000I The START HADR ON DATABASE command completed successfully.
第八步，检查状态，验证 HADR 状态：
清单 9. 验证 HADR 状态
# 在 host1 上
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host1.ibm.com host2.ibm.com
PRIMARY 2 REMOTE_CATCHUP host1.ibm.com host3.ibm.com
2 record(s) selected.
这里在验证 HADR 运行状态的时候，用到了监视器函数 MON_GET_HADR，该函数是 DB2 LUW V10.1 新引入的、用来返回 HADR 实时情况的表函数，DB2 同时还提供了新的 db2pd 的命令行接口。关于这两个监视工具的详细使用方法以及返回内容的具体含义，请参考本文末尾参考资源中的 DB2 信息中心。
至此，一个完整的 HADR 多备机环境已经配置完成。
刚才已经提到，HADR 多备机新特性支持动态添加、删除辅助备机。清单 10 中演示了如何动态添加一个辅助备机：只需在新的辅助备机上从主数据库备份镜像中还原出主数据库，配置好 HADR 参数之后，将其启动为备机数据库；然后在主机上修改 HADR_TARGET_LIST 这一数据库参数，将该新辅助备机数据库服务器名和端口号添加到 HADR_TARGET_LIST 之中即可，该辅助备机将在 HADR_TARGET_LIST 参数修改完成后实时生效，无需重行启动主数据库上的 HADR 服务（STOP HADR 后 START HADR AS PRIMARY），更无需重启主数据库（DEACTIVATE DATABASE 后 ACTIVATE DATABASE）。
清单 10. 动态添加辅助备
# 在 host4 上
db2 RESTORE DB MYDB
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522|host1:41518
HADR_REMOTE_HOST host1
HADR_REMOTE_SVC 41518
HADR_SYNCMODE supersync
HADR_REMOTE_INST inst1
HADR_LOCAL_HOST host4
HADR_LOCAL_SVC 41524 "
db2 START HADR ON DB MYDB AS STANDBY
# 在 host1 上
db2 "UPDATE DB CFG FOR MYDB USING
HADR_TARGET_LIST host2:41520|host3:41522|host4:41524"
除了同步模式之外，主要备机和辅助备机是相同的。它们都是在重做（Replay）主数据库方面传送过来的数据库事务日志，这一点与 HADR 单一备机下的备机数据库完全相同。因此，原先单一备机环境下备机数据库的所有特性，在多备机环境下的主要备机和辅助备机都支持。清单 11 列出了如何在主要备机上接管 HADR，清单 12 则列出了如何在辅助备机上接管 HADR，二者与单一备机下的备机数据库接管 HADR 完全相同。
清单 11. 主要备机接管 HADR
# 在 host2 上
db2 TAKEOVER HADR ON DB MY DB
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host2.ibm.com host1.ibm.com
PRIMARY 2 REMOTE_CATCHUP host2.ibm.com host3.ibm.com
PRIMARY 3 REMOTE_CATCHUP host2.ibm.com host4.ibm.com
3 record(s) selected.
清单 12. 辅助备机接管 HADR
# 在 host3 上
db2 TAKEOVER HADR ON DB MY DB
db2 "select HADR_ROLE, STANDBY_ID, HADR_STATE,
varchar(PRIMARY_MEMBER_HOST,20) as PRIMARY_HOST,
varchar(STANDBY_MEMBER_HOST,20) as STANDBY_HOST
from table (mon_get_hadr(NULL))"
HADR_ROLE STANDBY_ID HADR_STATE PRIMARY_HOST STANDBY_HOST
------------- ---------- ----------------- ------------- --------------
PRIMARY 1 PEER host3.ibm.com host2.ibm.com
PRIMARY 2 REMOTE_CATCHUP host3.ibm.com host1.ibm.com
PRIMARY 3 REMOTE_CATCHUP host3.ibm.com host4.ibm.com
3 record(s) selected.
在接管之后，MON_GET_HADR 返回的 HADR 状态也会实时更新。
注意，在单点模式下，同步模式配置的规则和以前的版本没有区别。但是在多点模式下，主要备机的同步模式取决于主机的同步模式，而非自己的参数配置。而辅助备机的同步模式必须为超级异步模式，本数据库中的该配置会被忽略。举个例子，对于以下配置的四台机器。以为 host1 的主要备机是 host2,，所以，host2 的实际同步模式是近同步，而非自己配置的同步，如图三所示。
图 3. 实际同步模式取决于主机和备机角色
实际同步模式取决于主机和备机角色
备机配置中的同步模式会在接管以后起作用，例如实例中，host2 上发生 takeover 以后，就会变成以下的配置，如图 4 所示。
图 4. 接管后备机上的同步模式才起作用
接管后备机上的同步模式才起作用
日志假脱机（Log Spooling）
前面已经提到这个功能主要是为了缓解备机对主机造成的压力。它的作用和超级异步模式类似。但是超级异步模式下，如果备机重做的慢，主机上的日志就不能传到备机上。一旦发生事故需要接管，事务就会丢失。而日志假脱机是把日志保存在备机上，只是重做的时机不能和主机同步。即使接管，已经保存的事务也不会丢失，但是接管的时间可能会相对长一点。
为了使能这个功能，需要配置一个新的数据库参数 HADR_SPOOL_LIMIT。该参数制定了最多可以再硬盘上缓冲多少日志。它的单位是 4K。如果它的值是 0，代表没有使能该功能；如果它的值是 -1，代表缓冲区没有限制。
重演延迟（Delayed Replay）
该功能主要是为了在主机由错误操作的情况下，备机可以快速的恢复到误操作以前的数据。DB2 V10.1 中，增加了数据库配置参数 HADR_REPLAY_DELAY 对该功能进行配置。该参数制定了延时重做的时间。它以秒为单位，0 代表不打开该功能。如果日志的时间戳小于备机上当前的时间减去 HADR_REPLAY_DELAY 的值，就不去应用该日志。基于这个原理，主机和备机的时间同步是很重要的。
该功能只在 HADR 的备机上支持，如果主机配置了该参数，启动的时候就会报错。该功能只支持超级异步模式的备机，而且，使能了该功能的备机不支持接管。
如果用户使用了该功能，作者建议同时使能日志假脱机。这样，就会有尽可能多的日志保存在备机上，而使备机前滚到尽可能晚的位置。我们举一个反例，如果 HADR_REPLAY_DELAY 被设置成了两个小时，但是备机的接收缓存（内存和磁盘缓存的总和，即 HADR 内存接收缓存和 HADR_SPOOL_LIMIT 的总和）只能保存一个小时产生的日志。一旦主机发生意外停机，备机将不能恢复到一小时之后的位置，因为那些位置的日志没有传到备机上。
重演延迟示例
这里，作者通过以下的实例来展示一下改功能。为了能在备机上进行查询，作者在备机上打开了 RoS（Read on Standby），简单起见，作者使用的是单一备机模式。
清单 13. 备机上的设置
sfbao@skua:~>db2set
DB2_STANDBY_ISO=UR
DB2_HADR_ROS=1
接下来，我们设置一个 HADR 环境，然后更新配置：
清单 14. 重演延迟的数据库设置
# 备机上：
sfbao@skua:~>
db2 update db cfg for hadrdb using HADR_LOCAL_HOST skua HADR_REMOTE_HOST tern
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 update db cfg for hadrdb using HADR_SYNCMODE superasync
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 update db cfg for hadrdb using HADR_REPLAY_DELAY 600
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@skua:~>db2 start hadr on db hadrdb as standby
DB20000I The START HADR ON DATABASE command completed successfully.
# 主机上：
sfbao@tern:~>db2 update db cfg for hadrdb using hadr_syncmode superasync
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
sfbao@tern:~>db2 start hadr on db hadrdb as primary
DB20000I The START HADR ON DATABASE command completed successfully.
通过 db2pd -hadr 查看一下状态：
清单 15. 检查 HADR 状态
sfbao@skua:~>db2pd -db hadrdb -hadr | grep HADR_STATE
HADR_STATE = REMOTE_CATCHUP
因为是 superasync mode，数据库一直处于 remote catchup 的状态。这个结果表明 HADR 启动成功。
接下来，我们在主机上创建一个表：
清单 16. 在主机上创建表
sfbao@tern:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
sfbao@tern:~>db2 "create table t(id int, name char(254))"
DB20000I The SQL command completed successfully.
然后我们到备机上查询一下：
清单 17. 连接备机失败
sfbao@skua:~>db2 connect to hadrdb
SQL1776N The command cannot be issued on an HADR standby database. Reason
code = "4".
备机返回错误，怎么回事？这是因为 ROS 的限制：当 DDL 在备机上重做的时候，备机不接收新的连接。从 db2pd -hadr 里面我们也可以看出来，这个时候，Replay Only Window 是活动的：
清单 18. 检查 HADR 的 Replay Only Window
sfbao@skua:~>db2pd -db hadrdb -hadr | grep REPLAY_ONLY_WINDOW
STANDBY_REPLAY_ONLY_WINDOW_ACTIVE = Y
STANDBY_REPLAY_ONLY_WINDOW_START = 04/16/2012 00:28:35.000000 (1334561315)
STANDBY_REPLAY_ONLY_WINDOW_TRAN_COUNT = 1
十分钟以后，我们重新连接到备机：
清单 19. DDL 重演被推迟
sfbao@skua:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
连接成功，说明这条 DDL 被延时了 10 分钟重做。我们在主机上插入一条数据，注意，我们这里使用了自动提交（Auto Commit）：
清单 20. 在主机上插入数据
sfbao@tern:~>db2 "insert into t values(1, 'hello')"
DB20000I The SQL command completed successfully.
然后在备机上查询一下：
清单 21. 检查备机上的数据
sfbao@skua:~>db2 "select * from t"
ID NAME
----------- --------------------------------------
1 hello
1 record(s) selected.
竟然查了出来，这又是怎么回事呢？这个是因为在 DB2 中，并不是每个日志记录都包含时间戳。一个打开自动提交的 insert 操作其实包含两部分的日志记录：insert 和 commit 的。当 insert 这部分传过来以后，这部分首先被重做了，所以可以从备机上查看到这个记录。但是实际上，这个操作并没有提交，也就是 commit 这部分并没有重做。这个时候，如果用一下的方式停掉备机上的 HADR，并且不进行前滚操作，就会得到以下结果：
清单 22. 停止 HADR 并检查备机上的数据
sfbao@skua:~>db2 deactivate db hadrdb
DB20000I The DEACTIVATE DATABASE command completed successfully.
sfbao@skua:~>db2 stop hadr on db hadrdb
DB20000I The STOP HADR ON DATABASE command completed successfully.
sfbao@skua:~>db2 rollforward db hadrdb complete
Rollforward Status
Input database alias = hadrdb
Number of members have returned status = 1
Member ID = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000000.LOG - S0000000.LOG
Last committed transaction = 2012-04-16-08.12.25.000000 UTC
DB20000I The ROLLFORWARD command completed successfully.
sfbao@skua:~>db2 connect to hadrdb
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0
SQL authorization ID = SFBAO
Local database alias = HADRDB
sfbao@skua:~>db2 "select * from t"
ID NAME
----------- --------------------------------------
0 record(s) selected.
这个结果表明，commit 语句其实在之前并没有被重做。
回页首
监控接口
DB2 V10.1 中 HADR 的监控内容更加丰富，用户可以从里面提取更多有用的信息。本文之前的部分，我们已经列出了一些监控的输出，其中有一些内容和以前的版本一致，请参考本文末尾的参考资源中“DB2 HADR 监控详解”一文。这里，我们不再进行说明，以下仅简单介绍监控输出的新内容：
REPLAY_TYPE，LOG_STREAM_ID 和 PRIMARY_MEMBER 的值目前为固定值，本文不对这几项进行解释；
STANDBY_ID：备机的编号，在多备机环境下，每台备机对于主机来说都有一个编号，这个编号从 1 开始；
PRIMARY_MEMBER_HOST：主数据库的主机名，相当于以前的 hadr_local_host；
STANDBY_MEMBER_HOST：备机数据库的主机名，相当于以前的 hadr_remote_host；
HADR_CONNECT_STATUS：当前的连接状态；
HADR_CONNECT_STATUS_TIME：HADR 变成当前连接状态的时间；
TIME_SINCE_LAST_RECV：网络上上一次收到数据的时间；
LOG_HADR_WAIT_CUR，LOG_HADR_WAIT_RECENT_AVG，LOG_HADR_WAIT_ACCUMULATED，LOG_HADR_WAIT_COUNT：从以上的参考资料中可以看出来，在同步、近同步、异步三种模式下，主机上的事务需要等待 HADR 将日志传输完成才可以提交，这四个参数是为了监控主机等待 HADR 传输日志用了多长时间，也就是 HADR 的开销。他们分别显示了当前的事务在 HADR 传输日志中等待的时间、最近几次等待时间的平均值、从 HADR 启动开始到当前时间内 HADR 传输日志总共用的时间、一共发生了多少次等待。因为每次传输日志都会等待，所以最后一个参数其实也代表了 HADR 一共传输过多少次日志或者说日志一共有多少次写操作；
PRIMARY_LOG_FILE, PAGE, POS：主机上最新的日志的位置；
STANDBY_LOG_FILE, PAGE, POS：备机上接收的最新的日志的位置；
STANDBY_REPLAY_LOG_FILE, PAGE, POS：备机重做的最晚的日志的位置。如果主机和备机的日志的位置差距大，表明日志不能即时传输；如果日志被重做的位置和备机接收的日志的位置差距大，表明备机重做的效率不高；
PRIMARY_LOG_TIME，STANDBY_LOG_TIME，STANDBY_REPLAY_LOG_TIME：分别表示主机上最新的日志的时间，备机接收的最新的日志的时间和备机重做的最新的日志的时间。
回页首
总结
DB2 LUW V10.1 在 HADR 方面的增强极大地提高了 DB2 的高可用性和灾备能力。考虑到高可用性（High Availability，HA）和灾难恢复（Disaster Recovery）本质上来说有着不同的业务需求：高可用性要求主数据库和备机数据库距离尽可能短，这样才能在主数据库出现故障时，备机数据库尽可能快地接管，从而缩短数据库服务中断的时间。而灾难恢复则希望主数据库在被地震、火灾等摧毁后，从备机还能恢复出主数据库中的数据。由于该类灾难影响的范围通常较大，所以从灾难恢复的角度出发，备机数据库与主数据库的距离应尽可能的远。二者矛盾的需求导致了不可能仅使用单个备机数据库来同时实现二者的要求，因此，新版本的 DB2 引入了 HADR 多备机的新特性，通过该特性，用户可以配置多于一个的备机数据库，轻松同时实现高可用性的目标以及提供灾难恢复的支持。同时，新版本的 DB2 对性能问题也有更好的处理，而且重演延迟这个功能还使得 HADR 有了一定程度的纠错能力。监控方面也更全面，用户可以轻松的判断出当前系统的压力，可以容易的判断出来当前 HADR 的性能瓶颈在于网络还是机器性能。 收起