基于HADR高可用方式的开放平台DB2数据库故障恢复方案

背景：

HADR（High Availability Disaster Recovery）是DB2数据库级别的高可用性数据复制机制。在开放平台中，DB2的HADR环境由一台主数据库服务器和一台备用数据库服务器组成，当主数据库中发生事务操作时，会同时将日志文件通过TCP/IP协议传送到备用数据库，然后备库对接收到的日志进行重放（REPLAY），从而保证一致性。当主库发生故障时，备库可以接管主库的事务处理。本文我们就来分享基于HADR高可用方式的DB2数据库进行故障恢复的方案

场景描述：

HADR高可用环境的DB2数据库，主机A节点和备机B节点的数据库分别以PRIMARY和STANDBY角色正常运行。模拟主库的活动日志所在的文件系统遭到破坏，数据库活动日志丢失，直接导致数据库不可用的场景。

处置方案：

为了使数据库尽快恢复使用，应该第一时间进行故障转移，令备机B节点接管数据库服务，再对发生故障的A节点进行恢复。

1 故障转移

HADR提供了两种接管方式：普通接管和紧急接管。普通接管的命令如下：

普通接管必须在主数据库和备用数据库都正常运行的情况下使用，而在本次的模拟场景中主数据库发生故障，普通接管将失败，这时候必须使用紧急接管，命令如下：

当主备数据库的HADR处于对等状态（PEER）时，两者之间可以通过日志传输和重放保证一致性，但是由于在B紧急接管后，此时A还没有进行数据库的恢复，因此B节点和A节点无法建立对等状态，可能导致数据库异常。所以应该停止主数据库和备用数据库的HADR同步。

这里补充说明一下，DB2 HADR提供了三种日志同步方式：SYNC（同步）、NEARSYNC（接近同步）和ASYNC（异步）。在本场景中使用的是NEARSYNC模式；这种情况下，B在收到A收到日志后发出的应答时即认为日志写入成功，然而A由于本地数据库日志文件系统遭到破坏，无法将日志持久化及重放。因此AB间不仅无法达成高可用，还可能引发其他问题。停止HADR的命令如下：

在B节点上发出此命令，所有的HADR连接都被断开，数据库恢复为单机数据库，并保持联机状态。在A节点上使用DEACTIVATE DATABASE命令停止数据库，如果正常停止数据库失败，则直接使用DB2KILL -ALL停止数据库。

由于采用了归档日志文件记录，所以当B节点接管数据库后，会自动被置于前滚暂挂状态（ROLLFORWARD-PENDING），数据库将处于不访问的状态，这样就必须使用前滚工具来前滚数据库，从而使数据库可以访问。前滚操作命令如下：

至此，故障转移顺利完成，B节点接管数据库服务，而A节点需要立即进行数据库恢复，并重新加入到HADR集群中。

2 HADR恢复

要恢复HADR集群，首先要在A节点通过备份恢复的方式将数据库进行恢复，然后在重新配置HADR集群。

数据库的恢复并不复杂，可以通过在线或离线备份并在A节点使用备份文件进行恢复即可。在本场景中，我们选择了离线备份B节点的数据库，然后在A节点通过备份文件重建数据库。如果选择在线备份，恢复时需要从备份文件中提取日志，并根据这些日志进行前滚操作。

离线备份需要先对数据库取消激活（DEACTIVATE）并保持DB2实例正常运行，取消激活前必须断开所有数据库连接，此处提供一个小窍门：临时清除DB2连接方式配置项（重启实例生效）来阻止产生新的连接，再断开所有已有的连接。B节点操作如下：

A节点上的数据库恢复操作比较常规，DROP删除旧库，然后RESTORE重建：

这个过程也会对DB CFG进行RESTORE，所以一定要检查HADR配置项，尤其HADR_LOCAL_HOST和HADR_REMOTE_HOST两项需要重设，然后按照先从后主的顺序重启HADR。A节点HADR配置：

HADR重新配置完成，只意味着DB2高可用性恢复了一半，因为HADR只提供了由数据库管理员手工TAKEOVER切换功能，而它并不能监控主数据库服务器上发生的故障，无法自动切换。所以我们还需要重配TSA，实现实例故障切换的自动化。依旧按照先从后主的顺序分别对两台服务器进行配置，并重启实例使TSA生效。：

总结：

本文以模拟场景中的一个故障为例，对DB2在HADR环境中的故障恢复方法和步骤进行了一次回顾和梳理，并涵盖了DB2故障转移、数据库备份恢复、HADR恢复以及TSA重建等方面。

开放系统支持部@ABCDC     陈依娇