方案: 在 Db2 pureScale 环境中部署 HADR

此场景描述了名为 ExampleFlightsExpress (EFE) 的在线旅行服务 (当前正在使用 Db2 pureScale 功能部件) 的高可用性灾难恢复 (HADR) 设置的规划，配置和部署。可以在不停机的情况下执行所有这些步骤。

背景

由于以下两个原因， EFE 选择使用 Db2 pureScale Feature:

连续可用性。停机时间对于客户差不多是一周七天每天 24 小时都在访问的在线零售业务是致命的。
可伸缩性。因为客户需求会随着时节的变化而起落，所以 EFE 必须能够轻松添加容量而不必停运。

EFE 已使用归档日志记录进行配置。除非发生大面积中断，导致整个 Db2 pureScale 集群宕机，否则 EFE 的设置具有弹性。为了解决此缺陷， EFE 将使用 HADR ，这受 Db2 pureScale Feature 支持。在 Db2 pureScale 环境中， HADR 有一些限制，例如不支持在备用数据库上读取，但这些限制是可接受的，因为 EFE 只希望 HADR 用于灾难恢复。

规划

EFE 打算使用公司的总办事处（站点 A）作为 HADR 主集群的位置，并使用一个 500 英里（800 公里）之外的区域办事处（站点 B）作为备用集群的位置。两个站点通过 WAN 连接在一起。以下是有关该环境的其他详细信息：

数据库名称：hadr_db
所有主机上的实例所有者：db2inst
用于 HADR 主数据库/备用数据库通信的 TCP 端口：4000
用于 SQL 客户机/服务器通信的 TCP 端口：8000
主服务器上的集群高速缓存工具 (标识为 128 和 129) 和成员 (标识为 0 ， 1 ， 2 和 3) 的主机: cfp0， cfp1， p0， p1， p2和 p3
备用数据库上集群高速缓存设施和成员的主机: cfs0， cfs1， s0， s1， s2和 s3

首选重放成员: 仅备用集群上的一个成员执行主集群上所有成员上生成的日志的所有重放。因此，EFE 的 DBA 确定主集群和备用集群中的哪些成员主机具有最多内存和 CPU 资源，并将那些成员指定为首选重放成员。甚至对于主数据库也有必要进行此规划，这是因为在主数据库发生故障并重新集成为备用数据库时，指定的成员将执行所有重放。在主数据库上，此主机是 p0，在备用数据库上，此主机是 s0；在这两种情况下，成员 0 是这些主机上的常驻成员。
同步方式: EFE 的 DBA 必须在同步方式 ASYNC（缺省值）、SYNC、NEARSYNC 与 SUPERASYNC 之间进行选择。为此，DBA 分析 WAN，并确定网络吞吐量为每秒 300 兆比特，往返时间为 80 毫秒。下一步，DBA 测量日志记录速率，在集群级别，这是每秒 20 MB。该网络吞吐量足以支持此日志记录速度并允许峰值日志记录速度达到每秒 37 MB，所以 ASYNC 是合适的方式。如果吞吐量与日志记录速度比较接近，那么 SUPERASYNC 是更好的选项，这是因为在峰值交易时间期间，它允许主数据库胜过备用数据库。
缩放注意事项: 由于 EFE 趋向于在高峰时节添加临时成员，所以 EFE 必须决定如何扩充备用数据库，这是因为成员拓扑必须在 HADR 对之间相同。为了避免产生其他成本，EFE 决定在将主数据库上的其他成员部署在备用集群上时，它将使用主机上的多个成员。如果备用数据库必须执行接管成为新主数据库，那么这可能会使数据库的功能不够强大，但节约的成本可以抵销此可能的缺点。

配置 HADR

DBA 执行以下步骤：

DBA 对预期主数据库 hadr_db 进行联机备份：
```
db2 BACKUP DB hadr_db online TO backup_dir
```
DBA 通过发出以下命令将该备份复原到预期备用集群上：
```
db2 RESTORE DB hadr_db FROM backup_dir
```
在主数据库上，DBA 设置集群级别的 HADR 参数，这些参数指定备用集群和同步方式。 hadr_target_list 参数特别重要，它用于列示远程成员。在 hadr_target_list 中只需要列示一个远程成员。 Db2 在与所列成员初始联系后检索其他成员的地址。但是，提供多个地址可以防止发生单点故障，即，如果列示的唯一成员发生故障，那么集群将无法相互连接。 DBA 发出以下命令：
```
db2 "UPDATE DB CFG FOR hadr_db USING
     HADR_TARGET_LIST  {s0:4000|s1:4000|s2:4000|s3:4000}
     HADR_REMOTE_HOST  {s0:4000|s1:4000|s2:4000|s3:4000}
     HADR_REMOTE_INST  db2inst
     HADR_SYNCMODE     async"
```
因为只有一个备用数据库，所以 hadr_remote_host 参数将同一组地址指定为 hadr_target_list 参数。

DBA 在主数据库上设置成员级别 HADR 参数，这些参数标识每个成员的地址和端口：

对于成员 0：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 0 USING
     HADR_LOCAL_HOST   p0
     HADR_LOCAL_SVC    4000"

对于成员 1：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 1 USING
     HADR_LOCAL_HOST   p1
     HADR_LOCAL_SVC    4000"

对于成员 2：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 2 USING
     HADR_LOCAL_HOST   p2
     HADR_LOCAL_SVC    4000"

对于成员 3：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 3 USING
     HADR_LOCAL_HOST   p3
     HADR_LOCAL_SVC    4000"

在备用数据库上，DBA 设置集群级别的 HADR 参数，这些参数指定主集群和同步方式：

db2 "UPDATE DB CFG FOR hadr_db USING
     HADR_TARGET_LIST  {p0:4000|p1:4000|p2:4000|p3:4000}
     HADR_REMOTE_HOST  {p0:4000|p1:4000|p2:4000|p3:4000}
     HADR_REMOTE_INST  db2inst
     HADR_SYNCMODE     async"

DBA 在备用数据库上设置成员级别 HADR 参数，这些参数标识每个成员的地址和端口：

对于成员 0：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 0 USING
     HADR_LOCAL_HOST   s0
     HADR_LOCAL_SVC    4000"

对于成员 1：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 1 USING
     HADR_LOCAL_HOST   s1
     HADR_LOCAL_SVC    4000"

对于成员 2：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 2 USING
     HADR_LOCAL_HOST   s2
     HADR_LOCAL_SVC    4000"

对于成员 3：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 3 USING
     HADR_LOCAL_HOST   s3
     HADR_LOCAL_SVC    4000"

启动 HADR

与其他 HADR 一样，必须先启动备用数据库。因为从中发出 START HADR 命令的成员将指定为首选重放成员，所以 DBA 发出以下命令：

从备用数据库上的成员 0：
```
db2 START HADR ON DB hadr_db AS STANDBY
```
从主数据库上的成员 0：
```
db2 START HADR ON DB hadr_db AS PRIMARY
```

为了确定 HADR 是否已启动并正在运行，DBA 从主成员调用 MON_GET_HADR 表函数：

select LOG_STREAM_ID, PRIMARY_MEMBER, STANDBY_MEMBER, HADR_STATE
from table (mon_get_hadr(-2))

  LOG_STREAM_ID PRIMARY_MEMBER STANDBY_MEMBER HADR_STATE            
  ------------- -------------- -------------- -----------------------
  0             0              0              PEER
  1             1              0              PEER
  2             2              0              PEER
  3             3              0              PEER

DBA 通过查看以下信息来确认备用成员 0 (首选重放成员) 确实是当前重放成员:STANDBY_MEMBER字段。每个日志流都会报告备用数据库上的相同成员，这是因为主数据库上的所有成员都已连接到该备用成员。

角色切换

DBA 必须执行角色交换；即，当前备用角色将接管主角色，当前主角色将接管备用角色。这将允许某些维护需要在站点 A 上执行集群关闭。此过程在低使用率的时间内进行，以最小化当前连接到数据库的应用程序的影响。

DBA 确保主项上成员均不处于异常状态：

SELECT ID,  
       varchar(STATE,21) AS STATE, 
       varchar(HOME_HOST,10) AS HOME_HOST, 
       varchar(CURRENT_HOST,10) AS CUR_HOST, 
       ALERT 
FROM SYSIBMADM.DB2_MEMBER

ID     STATE                 HOME_HOST  CUR_HOST   ALERT
------ --------------------- ---------- ---------- --------
0      STARTED               p0         p0         NO
1      STARTED               p1         p1         NO
2      STARTED               p2         p2         NO
3      STARTED               p3         p3         NO

  4 record(s) selected.

DBA 确保所有日志流处于 PEER 状态：

select LOG_STREAM_ID, PRIMARY_MEMBER, STANDBY_MEMBER, HADR_STATE
from table (mon_get_hadr(-2))

  LOG_STREAM_ID PRIMARY_MEMBER STANDBY_MEMBER HADR_STATE            
  ------------- -------------- -------------- -----------------------
  0             0              0              PEER
  1             1              0              PEER
  2             2              0              PEER
  3             3              0              PEER

在场所 B，DBA 对成员 0 发出 TAKEOVER HADR 命令：
```
TAKEOVER HADR ON DB hadr_db
```
此命令完成后，新备用项上的成员 0（首选重放成员）将选作重放成员，且会在备用集群的其他成员上关闭数据库。在新主项上，数据库仅在成员 0 上激活；其他成员通过客户机连接或在 DBA 对每个成员显式发出 ACTIVATE DATABASE 命令的情况下激活。客户机自动重新路由将任何新客户机发送到场所 B。
在场所 A，DBA 在备用项上停用数据库（这使数据库保持处于 HADR 备用项的角色）：
```
DEACTIVATE DATABASE hadr_db
```
在站点 A 上， DBA 在备用数据库上停止 Db2 :
```
db2stop
```
在场所 A，DBA 执行所需维护。
在站点 A 上， DBA 在备用数据库上启动 Db2 :
```
db2start
```
在场所 A，DBA 在备用项上激活数据库：
```
ACTIVATE DATABASE hadr_db
```
数据库作为具有一个重放成员的 HADR 主项激活。
要还原为原始设置，DBA 在场所 A 对成员 0 发出 TAKEOVER HADR 命令：
```
TAKEOVER HADR ON DB hadr_db
```

故障转移

DBA 必须执行故障转移；即，在场所 A 发生意外中断的情况下，场所 B 的备用项需接管主角色。 Db2 pureScale 环境中的 HADR 的一个重要差异是，不支持使用 IBM® Tivoli® System Automation for Multiplatforms (SA MP) 来自动执行故障转移 (它已用于确保 Db2 pureScale 集群中的高可用性)。无论如何，在此场景中，DBA 都希望手动控制这种对中断的响应。

DBA 在场所 B 从备用数据库执行强制接管。
```
TAKEOVER HADR ON DB hadr_db BY FORCE
```
备用项会发送禁用消息以关闭主项。停止日志发送和检索后，备用项会完成其日志路径中任何日志的重放。最后，备用项成为新的主项。
DBA 对新主项发出 db2pd 命令以确保其已接管主角色。
```
db2pd -hadr -db hadr_db
```
解决中断原因并使场所 A 再次启动和运行后，DBA 会尝试重新将旧主项集成为备用项。
```
START HADR ON DB hadr_db AS STANDBY
```
DBA 通过以下方法确认场所 A 现在为备用项：检查 HADR_CONNECT_STATUS 和 HADR_STATE 字段以确保显示数据库已连接且处于对等或远程同步复制状态。
```
db2pd -hadr -db hadr_db
```
但是，由于两个场所的数据库的日志流分流，因此数据库会显示为已断开连接。 DBA 查看旧主项上其中一个成员的 diag.log 文件，看到一条消息，指示场所 A 的数据库不能与新主数据库保持一致。

DBA 必须删除数据库，并在场所 A 将其作为 HADR 备用项重新初始化。

删除数据库：
```
DROP DATABASE DB hadr_db
```

在场所 B 对数据库执行备份。

BACKUP DATABASE DB hadr_db ONLINE TO backup_dir

将备份映像复原到场所 A。
```
db2 RESTORE DB hadr_db FROM backup_dir
```

在场所 A 的数据库上设置集群级别和成员级别配置参数。

db2 "UPDATE DB CFG FOR hadr_db USING
     HADR_TARGET_LIST  {s0:4000|s1:4000|s2:4000|s3:4000}
     HADR_REMOTE_HOST  {s0:4000|s1:4000|s2:4000|s3:4000}
     HADR_REMOTE_INST  db2inst
     HADR_SYNCMODE     async"

对于成员 0：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 0 USING
     HADR_LOCAL_HOST   p0
     HADR_LOCAL_SVC    4000"

对于成员 1：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 1 USING
     HADR_LOCAL_HOST   p1
     HADR_LOCAL_SVC    4000"

对于成员 2：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 2 USING
     HADR_LOCAL_HOST   p2
     HADR_LOCAL_SVC    4000"

对于成员 3：

db2 "UPDATE DB CFG FOR hadr_db MEMBER 3 USING
     HADR_LOCAL_HOST   p3
     HADR_LOCAL_SVC    4000"

DBA 希望将成员 0 指定为首选重放成员，并在场所 A 上从成员 0 发出 START HADR 命令：
```
db2 START HADR ON DB hadr_db AS STANDBY
```
DBA 通过以下方法确认场所 A 现在为备用项：检查 HADR_CONNECT_STATUS 和 HADR_STATE 字段以确保显示数据库已连接且正同步复制到主项。
```
db2pd -hadr -db hadr_db
```
要还原至原始设置，DBA 可按先前部分中所述执行角色交换。