DB2High Availability Disaster Recovery(HADR) 是一个简单易用的数据复制特性，该特性为局部和全面站点故障提供一个高可用性（HA）解决方案。HADR(高可用性灾难恢复)是DB2数据库的一个组件，是DB2提供给用户的一种高可用性和灾难恢复的解决方案。组成HADR需要一对机器，一个主机和一个备机。它的基本原理是主机将数据库产生的日志通过网络传输到备机，然后备机将这些日志重新应用，整个过程类似于前滚恢复。从而保证主机和备机数据库的一致。当主机发生意外停机以后，例如停电或者灾难等，备机可以很快的接替主机继续工作。从DB2V97FP1 开始，HADR开始支持ROS(ReadOn Standby)，备机除了做备份数据库以外，还可以接收连接，执行读操作。
2.1、环境准备
主库:192.168.100.101 CM01
备库:192.168.100.102 CM11
2.2、主库配置
使用db2sampl命令创建样本db
db2sampl
打开主库日志归档模式
db2 update db cfg for <DBNAME> usingLOGARCHMETH1 LOGRETAIN
注：上面的命令将启用数据库以进行日志归档，并将日志保留在同一活动日志目录中。这还将使数据库处于备份挂起状态。
进行离线备份
db2 "backup database <DBNAME>"
注意：离线备份不是必需的。也可以使用在线备份。但是，在线备份可能需要更长的时间才能使HADR对进入对等状态。为了简单起见，我们在这里使用离线备份。
在主数据库上设置HADR cfg参数
db2 update db cfg for <DBNAME> usingHADR_LOCAL_HOST <IP ADDRESS OF PRIM>db2 update db cfg for<DBNAME> using HADR_LOCAL_SVC <PORT # on PRIM>db2update db cfg for <DBNAME> using HADR_REMOTE_HOST <IPADDRESS OF STNDBY>db2 update db cfg for <DBNAME> usingHADR_REMOTE_SVC <PORT # on STNDBY>db2 update db cfg for<DBNAME> using HADR_REMOTE_INST <INSTNAME OF STNDBY>db2update db cfg for <DBNAME> using LOGINDEXBUILD ON
进行脱机备份以用于设置HADR
db2 "backup database <DBNAME>"
2.3、备库配置
版本一致
确保两个服务器都在同一版本上，以免发生不匹配的情况。在两个服务器上运行“ db2level”命令，以检查它们是否在相同的DB2版本和修订包中。
通过FTP将备份映像（从主机）传输到备机
备库进行恢复
db2 "restore database DBNAME"
在备用数据库上设置HADR cfg参数。
db2 update db cfg for <DBNAME> usingHADR_LOCAL_HOST <IP ADDRESS ON STANDBY>db2 update db cfgfor <DBNAME> using HADR_LOCAL_SVC <PORT # ON STANDBY>db2update db cfg for <DBNAME> using HADR_REMOTE_HOST <IPADDRESS ON PRIM>db2 update db cfg for <DBNAME> usingHADR_REMOTE_SVC <PORT # ON PRIM>db2 update db cfg for<DBNAME> using HADR_REMOTE_INST <INSTNAME ON PRIM>
启动备机
db2 start hadr on database <DBNAME>as standby
在主服务器上启动HADR
db2 start hadr on database <DBNAME>as primary --验证HADR是否运行
db2pd -db <DBNAME>-hadr
2.4、两台机器之间进行角色切换的步骤
1. ON PRIMARY (CM01):
db2 connect to <dbname>2. ONPRIMARY (CM01):
db2 "create table tab1 (col1 int)"3.ON PRIMARY (CM01):
db2 "insert into tab1 values (1)"-insert 20 rows4. ON PRIMARY (CM01):
power down the Primary --> db2stopforce5. ON STANDBY (CM11):
db2 takeover hadr on database <dbname>by force6. The STANDBY instance on CM11 (DB2) is now theprimary7. ON CM11:
db2pd -db <dbname> -hadr (the ROLEshould state: PRIMARY)8. ON CM11:
db2 connect to <dbname>9. ONCM11:
db2 "select * from tab1" -Youshould see the 20 rows inserted10. ON CM11:
db2 "create table tab2 (col1int)"11. ON CM11:
db2 "insert into tab2 values (1)"-insert about 20 rows12. ON CM01:
db2 start hadr on database <dbname>as standby13. ON CM01:
db2pd -db <dbname> -hadr (the ROLEshould state: STANDBY)14. on CM01:
db2 takeover hadr on database <dbname>15.on CM01:
db2pd -db <dbname> -hadr (the ROLEshould state: PRIMARY)16. ON CM01:
db2 "select * from tab2" -youshould be able to see the 20 rows inserted17. on CM11:
db2pd -db <dbname> -hadr (the ROLEshould state; STANDBY)
注意：
1.两台服务器上的HADR对的主机名不能相同。
2.UNIX系统上的实例名称和基础用户ID可以不同。确保将dbcfg参数HADR_REMOTE_INST的实例的正确名称更新为正确的值。
1.SYNC（同步）
在四种方式中，此方式将最大可能地避免事务丢失，但使用此方式会导致事务响应时间最长。在此方式中，仅当日志已写入主数据库上的日志文件，而且主数据库已接收到来自备用数据库的应答，确定日志也已写入备用数据库上的日志文件时，方才认为日志写入是成功的。保证日志数据同时存储在这两处。
2.NEARSYNC（接近同步）
此方式具有比同步方式更短的事务响应时间，但针对事务丢失提供的保护也较少。在此方式中，仅当日志记录已写入主数据库上的日志文件，而且主数据库已接收到来自备用系统的应答，确定日志也已写入备用系统上的主存储器时，方才认为日志写入是成功的。仅当两处同时发生故障，并且目标位置未将接收到的所有日志数据转移至非易失性存储器时，才会出现数据的丢失。
3.ASYNC（异步）
与SYNC和NEARSYNC方式相比，ASYNC方式使事务响应时间更短，但在主数据库出现故障时，导致事务丢失的可能性更大。
在ASYNC方式下，仅当日志记录已写入主数据库上的日志文件，并且已传递到主系统的主机的TCP层时，才认为日志写入成功。因为主系统不会等待来自备用系统的确认，所以当事务仍处于正在传入备用数据库的过程中时，可能会认为事务已落实。
4.SUPERASYNC（超级异步）
此方式具有最短的事务响应时间，但在主系统出现故障时，此方式导致事务丢失的可能性也最大。当您不希望事务由于网络中断或拥塞而受到阻塞或经历较长的响应时间时，此方式很有用。
在此方式下，HADR对永远不会处于对等状态或断开连接的对等状态。只要日志记录已写入主数据库上的日志文件，就认为日志写入成功。由于主数据库不会等待来自备用数据库的确认，所以无论事务的复制状态如何，都会认为已落实该事务。
