转载

在 IBM PureData System for Transactions 中实现灾难恢复

简介

企业应用程序需要一个持续可用的数据源来保持工作流以最高效率运行。由于局部灾难引发的任何停机都可能让任务关键型数据库不可访问。最大限度地减少停机时间和数据损失不只是一个业务需求；而是经营上的必要条件。

本文概述了 IBM PureData System for Transactions 修订包 3 或更高版本上 DB2 V10.5 灾难恢复 (DR) 解决方案的设置和运行。该解决方案基于 DB2 高可用性和灾难恢复 (HADR) 特性，并且包含并非 HARD 特性直接处理的其他元素。HADR 将任何数据变更从主数据库源复制到备用数据库目标。这一技术完全集成到了 DB2 中，并且在主备数据库系统之间使用标准的 TCP/IP 网络接口。HADR 为计划内和计划外事件提供快速接管操作。

IBM PureData System for Transactions 中的 HADR 旨在提供系统、实例和数据库级的灾难恢复。这一解决方案需要两个 PureData System for Transactions 系统。系统接管通过高可用性和灾难恢复命令手动实现，并且可以集成到您的企业灾难恢复战略中。

该场景涵盖整个生命周期：设置、正常操作和执行接管。

灾难恢复系统配置

本文为一个涉及到具体 IBM PureData System for Transactions 配置的灾难恢复解决方案提供指导。用于描述概念和任务的配置包含两个系统（称为系统 A 和系统 B）。为了适应一个站点范围的灾难恢复场景，备用系统必须位于地理位置不同的数据中心。在该场景中，一个系统（系统 A）托管所有主数据库，而另一个系统（系统 B）托管所有备用数据库。在进行灾难恢复配置之前，系统 A 已经拥有针对数据库运行的应用程序工作负载了。因此，当您将系统 B 添加为备用系统时，该场景旨在最大限度地减少对原始系统 A 的中断。

本文中的说明使用以下配置和设置描述的环境：

清单 1. 配置设置

Primary System == System A   DB2 Instance == hdrinst1 (small)   2CF + 2Member   0 rack6_c2_ite0.example.com 0 rack6_c2_ite0 – MEMBER   1 rack6_c2_ite1.example.com 0 rack6_c2_ite1 – MEMBER   128 rack6_c2_ite0.example.com 0 rack6_c2_ite0 – CF   129 rack6_c2_ite0.example.com 0 rack6_c2_ite1 – CF      DB2 Database == foo_db   TCPIP Client/Server port (SVCENAME) == 65100    Standby System == System B   DB2 Instance == hdrinst1 (small)   2CF + 2Member   0 rack7_c2_ite2.example.com 0 rack7_c2_ite2 – MEMBER   1 rack7_c2_ite3.example.com 0 rack7_c2_ite3 – MEMBER   128 rack7_c2_ite2.example.com 0 rack7_c2_ite2 – CF   129 rack7_c2_ite3.example.com 0 rack7_c2_ite3 – CF      DB2 Database == foo_db   TCPIP Client/Server port (SVCENAME) == 65100

灾难恢复机制

在 IBM PureData System for Transactions 中，HADR 被配置并在每个数据库上运行。与标准 DB2 HADR 一致，系统的某些方面在两个系统上必须是一致的，才能让备用系统在接管操作之后正常运行。主备系统的以下方面必须保持一致：

DB2 数据库配置
DB2 实例配置
系统配置方面

回页首

PureData 上下文中的 HADR

尽管大部分 HADR 概念和任务适用于 PureData System for Transactions 上的 HADR，不过有一些特有的考虑因素。

首先，一个 PureData 系统托管 DB2 pureScale® 实例，要在 DB2 pureScale 实例中使用 HADR，有一些特殊的考虑因素。如欲了解详细信息，请参阅 DB2 Information Center 中的 DB2 pureScale 环境中的高可用性灾难恢复。

其次，系统拥有用于部署和管理数据库的内置功能。与其他 DB2 HADR 环境相比，这些功能具有某些优势和限制。

本文的主要目的是专为 PureData System for Transactions 提供指导。

回页首

涉及到灾难恢复的任务

我们将描述的任务假定主系统（系统 A）处于工作状态，正在运行数据库工作负载。另一个系统（系统 B）是在另一个数据中心内建立的。系统 B 是为防止一场灾难导致系统 A 无法处理数据库事务而建立的备用系统。

任务：配置系统级方面

在该任务中，您要在系统 A 与系统 B 数据网络之间建立 TCP/IP 网络连接。系统 A 中的所有成员都可以访问系统 B 中的所有成员，反之亦然。

任务：在备用系统上设置每个 DB2 实例

在该任务中，您要完成以下步骤：

基于系统 A 上的现有实例在系统 B 上部署一个实例。
定义一个在系统 A 与系统 B 之间传播实例级变更的策略，保持主备实例相同。

任务：为 DB2 实例中的每个数据库配置 HADR

该任务包括以下工作：

在系统 A 上的已部署实例中部署一个新数据库。
将系统 A 数据库的数据库备份还原到系统 B 上新部署的数据库中。
定义一个在系统 A 与系统 B 之间传播数据库级变更的策略，确保数据库参数保持一致。
在系统 A 和系统 B 上配置和启动 HADR 操作。

此时，HADR 经过配置，这样系统 A 就会受到系统 B 的保护。

任务：在 HADR 环境中使用 PureData 特性

该任务包括主系统（系统 A）或备用系统（系统 B）上的标准操作。

对于主系统，引入 HADR 对标准操作影响很小或没有影响。在备用系统上，数据库备份或连接操作不受支持，因为数据库是一个备用角色。

任务：在 PureData 系统中执行接管

该任务包括执行因计划内或计划外事件而引起的接管。

与典型 DB2 pureScale 系统相比，IBM PureData System for Transactions 系统上无针对 HADR 接管操作的特殊考虑因素。

回页首

系统级方面

系统级设置是指在供数据库管理员使用之前在系统上执行的必要初始配置。本节涵盖由系统管理员处理的硬件、网络和数据中心集成任务。

硬件先决条件

主备系统都必须是 IBM PureData System for Transactions。备用系统必须与需要 HADR 功能的主系统实例有同样数量的计算节点/成员。这一要求可确保主实例使用的所有计算节点/成员都具有备用系统的功能。

安全性先决条件

如果您的系统通过控制台用户控制安全性：

必须在主系统和备用系统上创建密码相同的用户帐户。这是确保任何灾难恢复事件不中断用户访问所必需的配置。
对于 HADR 配置任务，两个系统上的控制台用户都必须拥有 创建新 DB2 pureScale 实例 的权限才能部署实例。

如果您的系统使用 LDAP 用户和组进行安全性处理：

主备系统必须访问相同的 LDAP 服务器内容。这是确保任何灾难恢复事件不中断用户访问所需的配置。
在部署实例之前，您必须通过 Workload Console 配置和启用 LDAP 插件。单击 Cloud > System Plug-ins 。选择 LDAP 插件并单击 Configure 。联系您的 LDAP 管理员来填充插件配置细节。
对于 HADR 配置，LDAP 帐户必须拥有 创建新 DB2 pureScale 实例 的权限才能部署实例。

主系统和备用系统必须使用相同形式的身份验证，要么使用 LDAP，要么使用控制台帐户。混合安全方法不受支持。

用户授权级别

执行 HADR 配置程序的用户必须是实例所有者或其指定代理，或者具有 SYSADM 或 SYSCTL 权限的数据库所有者。该用户必须同时存在于两个系统上。

实例所有者，或在实例上具有管理员权限的任何其他控制台用户，可以通过 Workload Console 将适当的 DB2 管理授权书授予一个实例或数据库级用户。

实例级用户从 DB2 pureScale Instances 面板上进行管理（单击 Database > DB2 pureScale Instances ）。选择实例并将用户帐户添加到 Access granted to 列表。

数据库级用户从 Databases 上加以管理（单击 Database > Databases ）。选择数据库并将用户帐户添加到 Access granted to 列表。

网络

一个网络管理员必须将主备系统连接到一个现有的高速、大容量 TCP/IP 网络，该网络链接到数据中心。主系统中的每个成员必须能够访问备用系统中的成员。

您可以验证正确的网络配置，方法就是登录到主系统实例上的每个成员，确认您可以 ping 备用系统中的每个成员。类似地，登录到每个备用系统实例上的每个成员，确认您可以 ping 每个主系统实例成员。

配置 Tivoli Storage Manager 访问

为了方便备用系统上的数据库还原操作，必须确保备用系统能够访问主系统上捕获的数据库备份映像。

在进行配置之前，在两个系统均可访问的一台中央服务器或通过 Tivoli Storage Manager 节点复制连接到彼此的独立 Tivoli Storage Manager 服务器上，确保已安装和配置了 Tivoli® Storage Manager。

在部署实例之前通过 Workload Console 配置和启用 TSM 插件。单击 Cloud > System Plug-ins 。选择 TSM 插件并单击 Configure 。

回页首

工作负载级设置

工作负载级设置是指 PureData System for Transactions 中所需的数据库工作负载配置。这一配置通常由数据库管理员处理，并且分为两个级别：

托管一个或多个备用数据库的每个 DB2 实例所需的设置
每个 DB2 pureScale 备用数据库所需的设置

在备用系统上设置 DB2 实例

在备用系统上部署一个 DB2 版本 10.5 实例。可以为灾难恢复配置主系统上 DB2 版本 10.5 实例中的任何或所有活动数据库。

要设置一个备用实例：

在备用系统上部署一个新实例。在 Workload Console 中，单击 Database > DB2 pureScale Instances 。在该面板上，单击绿色的 + 图标，然后指定新实例选项。这一实例必须与主活动实例具有相同的大小，具有相同数量的 DB2 pureScale 成员。备用实例也应当与主实例具有相同的名称。

为备用实例所有者创建并更新任何特定于控制台的用户帐户（如果还未这么做），提供对该实例的访问。

如果您更新了主系统上的默认实例配置设置，对备用系统上的新备用实例做了同样的更改，确保在 HADR 接管过程之后操作能够顺利进行。

附录 B包含一段自动比较和更新主备系统上的配置设置的脚本的详细信息。

回页首

HADR 端口

主数据库和备用数据库都需要一个 HADR 服务端口。如果在同一实例上为 HADR 配置了多个数据库，则需要为每个数据库定义一个端口。

如果主系统和备用系统之间有一个防火墙，确保为数据库使用的端口（包括 HADR 端口）在两个方向上都定义了异常。

用于 HADR 服务的端口不应与对典型 DB2 数据库操作使用的任何端口相同。默认的 DB2 pureScale 端口是 50001、56000、56001 和 60000 - 60004。

在 HADR 设置期间，在数据库参数 HADR_LOCAL_SVC 、 HADR_REMOTE_HOST 和 HADR_TARGET_LIST 中使用了已定义的端口。

您的网络管理员必须配置网络连接路由，以便系统 A 中的所有成员可以访问系统 B 中的所有成员，反之亦然。

回页首

验证网络连接

要验证主系统与备用系统之间的连接：

在主系统上，在 Workload Console 中单击 Database > Databases 确定数据库拓扑。在 Show database members 中选择您的数据库并记录主机和 IP 地址值。
在备用系统上，通过重复备用系统上的上一步确认备用数据库的拓扑是相同的。主机数量应当相同，而且都应当有一个 STARTED 状态，不过主机和 IP 地址将不同。
在主系统的每个成员上，通过使用主机名 ping 每个备用系统成员测试连接。从主系统的成员 0 上，ping 备用系统的成员 0 和成员 1：
ping rack6_c2_ite0 ping rack6_c2_ite1
为主系统上的成员 1 重复此步骤。如果此步骤成功，则从备用系统到主系统重复此步骤。
如果上一步不成功，则使用 Workload Console 中显示的 IP 地址（而非备用系统节点的主机名）重复此过程：
ping 20.155.4.142 ping 20.155.4.143
如果此步骤成功，则从备用系统到主系统重复此步骤，然后继续 HADR 设置流程。如果此步骤不成功，则联系您的网络管理员检查主系统与备用系统之间的网络路由。

回页首

设置备用数据库

必须将主系统和目标系统上的数据库配置为具有相同的操作系统版本、DB2 版本、表空间配置和日志文件空间。

创建备用数据库

通过将现有主数据库的备份映像还原到备用系统，以便部署备用数据库。

在备用系统上：

使用 Workload Console，并将同一实例所有者帐户用作主实例（例如 hdrinst1），将一个具有相同数据库名称的空数据库部署为主数据库（例如 foo_db）。单击 Database > Databases 。在该面板上，单击绿色 + 图标，然后指定新数据库选项。
为了防止建立从 Database Performance Monitor 到数据库的连接，必须禁用数据收集。在 Workload Console 中，单击 Database > Database Performance Monitor 。单击 Databases 并从连接列表中选择空 HADR 数据库 (foo_db)。单击 Monitor 下拉列表并选择 Disable Automatic Collection 。
您还必须禁用数据库的健康警报。在 Database Performance Monitor 控制台中，单击 Health > Alerts 并打开 Health Alert Configuration 选项卡。选择空 HADR 数据库 (foo_db) 并删除 Monitor database health 上的对勾，然后单击 Apply。
将主系统数据库备份映像还原到备用系统上新的空数据库 (foo_db) 中。

要交付主数据库的备份映像：

在主系统上，使用 PureData System for Transactions 系统控制台中的备份面板将数据库备份到 Tivoli Storage Manager。
如果主系统和备用系统使用不同的 Tivoli Storage Manager 服务器，使用 Tivoli Storage Manager 节点复制将备份映像从主系统迁移到备用系统。
记录最近的时间戳并在备用系统上进行比较，确定同样的时间戳存在于备用系统上。

为了还原备份映像，您可以使用命令行从主备份还原备用数据库。

从备用系统上的命令行中：

在任何节点上运行还原命令。
db2 RESTORE DB <mydb> INTO <mydb> USE tsm TAKEN AT <timestamp>
其中 <mydb> 是数据库的名称， <timestamp> 可在主数据库备份交付任务中找到。

在备用系统上还原数据库时，将数据库保持在前滚挂起状态。否则，HADR start 命令无法完成，并让备用数据库处于失败状态。

为了完成部署，执行以下任务：

重新启用 Database Performance Monitor。在备用系统上，重新启用 Database Performance Monitor 数据收集。在 Workload Console 中，单击 Database > Database Performance Monitor 。单击 Database 并从连接列表中选择已还原的备用数据库副本 (foo_db)。单击 Monitor 下拉列表并选择 Enable Automatic Collection 。

Database Performance Monitor 不提供对备用系统数据库的监控，因为数据库是一个备用角色，不接受连接。然而，如果您对备用系统数据库启用了 Database Performance Monitor，那么监控操作将始于备用系统数据库采取主要操作时。

回页首

配置 HADR

背景

您必须是拥有执行这些操作的 SYSCTL 或 SYSADM 权限的数据库所有者或用户。

必须为每个备用数据库执行一次 HADR 配置任务。

附录 B包含的脚本指示了如何在主备系统上验证 HADR 数据库参数和自动化 HADR 配置流程。

确认为 HADR 配置将以下数据库参数设置为推荐值。在命令行中，运行以下命令：

db2 get db cfg for foo_db

LOGINDEXBUILD – 设置为 ON 。这一操作防止备用系统等待无效索引建立，并提供最佳的 HADR 性能。默认设置是 OFF 。
LOGARCHMETH1 – 设置为 TSM ；如将其设置为除 OFF 以外的值，则会禁用循环日志记录。当日志装满时，循环日志记录重用日志空间，如果日志未能在主日志填充并重置之前同步，则有可能导致事务丢失。当用 Tivoli Storage Manager 服务器注册系统时，该参数被设置为 TSM 。
INDEXREC – 如设置为 RESTART ，则会在接管时重建无效索引。默认设置是 RESTART 。

如果这些参数中有任何一个不正确，可以使用以下命令纠正其值：

db2 UPDATE DB CFG FOR <database> USING <parameter name> <parameter value>

以下参数使用的端口号不应与专用于主备 DB2 pureScale 实例的端口号相同：

HADR_LOCAL_HOST – 本地主机的名称。主系统上该参数的值应当与备用系统上 HADR_REMOTE_HOST 的值相同。备用系统上该参数的值应当与主系统上 HADR_REMOTE_HOST 的值相同。
HADR_TARGET_LIST – 代表备用数据库的目标主机和端口对的列表。
HADR_REMOTE_HOST - 远程主机的名称。主系统上该参数的值应当与备用系统上 HADR_LOCAL_HOST 的值相同。备用系统上该参数的值应当与主系统上 HADR_LOCAL_HOST 的值相同。
HADR_LOCAL_SVC – 本地 HADR 系统接受连接时的 TCP/IP 服务名或端口号。
HADR_REMOTE_INST – 远程实例的名称。该参数的值在主备系统上应当相同。

参见HADR 端口一节，了解 DB2 pureScale 数据库操作需要哪些端口。例如，在主系统上，参数可能如下所示：

HADR_TARGET_LIST {rack7_c2_ite2:4000|rack7_c2_ite3:4000} HADR_REMOTE_HOST {rack7_c2_ite2:4000|rack7_c2_ite3:4000} HADR_REMOTE_INST hdrinst1 HADR_SYNCMODE ASYNC

在备用系统上，参数将是类似的：

HADR_TARGET_LIST {rack6_c2_ite0:4000|rack6_c2_ite1:4000} HADR_REMOTE_HOST {rack6_c2_ite0:4000|rack6_c2_ite1:4000} HADR_REMOTE_INST hdrinst1 HADR_SYNCMODE ASYNC

流程

需要仅在群集中的一个成员上运行全局配置命令。配置更改适用于所有成员。

必须向每个成员应用成员级配置命令来更新本地 IP 地址或成员名。

所有命令都应当从 DB2 命令行运行。

首先在主系统（系统 A）、然后在备用系统（系统 B）上配置数据库的 HADR 设置（数据库配置值）。

在系统 A 上：

全局参数更新，可在任何成员节点上运行：

db2 "UPDATE DB CFG FOR foo_db USING  HADR_TARGET_LIST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}  HADR_REMOTE_HOST {rack7_c2_ite2:4000|rack7_c2_ite3:4000}  HADR_REMOTE_INST hdrinst1  HADR_SYNCMODE ASYNC"

成员级参数更新：

对于成员 0：

db2 "UPDATE DB CFG FOR foo_db MEMBER 0  USING HADR_LOCAL_HOST rack6_c2_ite0     HADR_LOCAL_SVC 4000"

对于成员 1：

db2 "UPDATE DB CFG FOR foo_db MEMBER 1  USING HADR_LOCAL_HOST rack6_c2_ite1     HADR_LOCAL_SVC 4000"

在系统 B 上：

全局参数更新，可在任何成员节点上运行：

db2 "UPDATE DB CFG FOR foo_db USING  HADR_TARGET_LIST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}  HADR_REMOTE_HOST {rack6_c2_ite0:4000|rack6_c2_ite1:4000}     HADR_REMOTE_INST hdrinst1     HADR_SYNCMODE ASYNC"

成员级参数更新：

对于成员 0：

db2 "UPDATE DB CFG FOR foo_db MEMBER 0 USING  HADR_LOCAL_HOST rack7_c2_ite2     HADR_LOCAL_SVC 4000"

对于成员 1：

db2 "UPDATE DB CFG FOR foo_db MEMBER 1 USING  HADR_LOCAL_HOST rack7_c2_ite3     HADR_LOCAL_SVC 4000"

在此阶段，HADR 相关参数被设置，系统准备启动 HADR 流程。

启动 HADR

在主系统（系统 A）上，必须在所有成员上对主数据库启动 HADR。在备用系统（系统 B）上，仅需要在一个成员上启动 HADR。这个成员被指定为首选重播成员。

在系统 B 上：

您必须在启动 HADR 之前停用备用系统上的数据库：

db2 DEACTIVATE DATABASE foo_db

对于成员 0，发出以下命令：

db2 START HADR ON DATABASE foo_db AS STANDBY

在系统 A 上：

对于所有成员，发出以下命令：

db2 START HADR ON DB foo_db AS PRIMARY

验证 HADR 正常运行：

在系统 A 上，调用 MON_GET_HADR 表函数：

db2 "SELECT LOG_STREAM_ID, PRIMARY_MEMBER, HADR_ROLE,  STANDBY_MEMBER, STANDBY_ID, HADR_STATE,  varchar(PRIMARY_MEMBER_HOST,30) AS PRMRY_MEMBER_HOST,  varchar(STANDBY_MEMBER_HOST,30) AS STNDBY_MEMBER_HOST     FROM TABLE (MON_GET_HADR(-2))"

样例输出：

LOG_STREAM_ID PRIMARY_MEMBER HADR_ROLE STANDBY_MEMBER ------------- -------------- --------- -------------- 1             1              PRIMARY   0 0             0              PRIMARY   0

样例输出（续）：

STANDBY_ID HADR_STATE PRMRY_MEMBER_HOST STNDBY_MEMBER_HOST ---------- ---------- ----------------- ------------------ 1          PEER       rack6_c2_ite1     rack7_c2_ite2 1          PEER       rack6_c2_ite0     rack7_c2_ite2

确认每个主成员都存在，并且每个成员都有 PRIMARY 的 HADR_ROLE 。

检查 STANDBY_MEMBER 字段，确认系统 B 上的成员 0（即首选重播成员）是当前的重播成员。每个日志流报告同一备用成员，因为所有主成员都连接到备用成员。

您也可以使用 db2pd 命令返回有关 HADR 环境的详细信息：

db2pd –db foo_db –hadr

清单 2. db2pd 命令的样例输出

Database Member 0 -- Database foo_db -- Active --    Up 0 days 01:00:24 -- Date 2013-07-24-20.33.16.378486      HADR_ROLE = PRIMARY      REPLAY_TYPE = PHYSICAL      HADR_SYNCMODE = ASYNC       STANDBY_ID = 1      LOG_STREAM_ID = 0       HADR_STATE = PEER       HADR_FLAGS =    PRIMARY_MEMBER_HOST = 20.155.4.140     PRIMARY_INSTANCE = hdrinst1     PRIMARY_MEMBER = 0    STANDBY_MEMBER_HOST = 20.155.2.140     STANDBY_INSTANCE = hdrinst1     STANDBY_MEMBER = 0    HADR_CONNECT_STATUS = CONNECTED HADR_CONNECT_STATUS_TIME = 07/24/2013 20:29:39.895023 (1374697779)

此时，您已经使用 HADR 为 IBM PureData System for Transactions 数据库成功配置了灾难恢复。

配置客户端重路由

在主系统上出现灾难恢复事件之后，如果您想让客户端应用程序自动路由连接请求到备用系统，那么您可以遵循本节的步骤。

成员级参数：

在系统 A 上：

对于成员 0：

db2 "UPDATE ALTERNATE SERVER FOR DATABASE foo_db     USING HOSTNAME rack7_c2_ite2 PORT 65100"

在系统 B 上：

对于成员 0：

db2 "UPDATE ALTERNATE SERVER FOR DATABASE foo_db     USING HOSTNAME rack6_c2_ite0 PORT 65100"

另外您可以使用 ADMIN_CMD 过程：

CALL SYSPROC.ADMIN_CMD ('UPDATE ALTERNATE SERVER FOR DATABASE foo_db     USING HOSTNAME rack7_c2_ite2 65100') CALL SYSPROC.ADMIN_CMD ('UPDATE ALTERNATE SERVER FOR DATABASE foo_db     USING HOSTNAME rack6_c2_ite0 65100')

无日志记录的操作

HADR 仅处理有日志记录的数据库操作；工作负载灾难恢复的其他方面必须另行解决。这些方面包括以下几项：

在系统级别设置操作系统用户 ID
实例级数据库管理器配置参数
实例级 DB2 注册表变量
数据库级数据库配置参数
在数据库级别还原外部例程

如果您对这些项目使用手动流程，则必须在常规操作期间发现它们，并将所有更改传播到备用系统。

附录 B详细描述了一个脚本，该脚本简化了在系统之间比较数据库和实例配置的任务。该脚本生成一个命令列表，这些命令是调整备用系统上的那些设置所必需的。

回页首

常规操作

系统运行状况

运行中的 HADR 服务提供若干指标来度量您的系统的运行状况。

在主系统上调用 MON_GET_HADR 表函数时，它同时在主备系统上返回有关 HADR 功能的信息。

然而，由于备用系统不接受客户端连接，可以使用 db2pd 命令直接在备用系统上查询信息。

从 MON_GET_HADR 表函数或 db2pd 命令返回的以下字段详述了您的连接状态：

HEARTBEAT_MISSED - 自数据库在本地成员上启动以来，为该日志流按时收到的 heartbeat 消息数量。
HEARTBEAT_EXPECTED - 自数据库在本地成员上启动以来，该日志流预计收到的 heartbeat 消息数量。将该值与 HEARTBEAT_MISSED 的值进行比较，可度量特定时间间隔期间的网络运行状况。
STANDBY_SPOOL_PERCENT - 使用的与已配置假脱机限制相关的假脱机空间的百分比。该值是衡量正在使用多少 HADR 日志假脱机空间的一个指标。
STANDBY_ERROR_TIME - 备用系统上一次遇到重大错误的时间。
HADR_CONNECT_STATUS - 数据库的当前 HADR 连接状态。可能的值包括 CONGESTED 、 CONNECTED 和 DISCONNECTED 。
TIME_SINCE_LAST_RECV - 自收到上一条消息以来经过的时间（毫秒级）。当该值超过已定义的心跳（heartbeat）间隔时，视为错过一个心跳。
STANDBY_RECV_REPLAY_GAP - 备用日志接收位置与备用日志重播位置之间的空隙中的平均字节数。该字段指明备用日志是否落后。当备用日志落后时，存在备用数据库停止接收日志并阻止主数据库的对等状态的风险。

参见 DB2 Version 10.5 Information Center 中的MON_GET_HADR 表函数，获取该表函数返回的监控信息的完整列表。

回页首

接管操作

计划内事件接管

您可以使用 DB2 TAKEOVER HADR 命令为规划内事件在主备数据库之间切换角色。

要执行数据库的规划内接管，可访问备用系统实例（系统 B）并发出以下 CLP 命令：

db2 TAKEOVER HADR ON DATABASE foo_db

运行 connect 命令确认数据库在系统 B 上可访问：

db2 CONNECT TO foo_db

此时，系统 B 上的数据库是主数据库，系统 A 上的数据库是备用数据库。

要从一个规划内接管事件中恢复过来（即让主数据库在系统 A 上运行，让备用数据库在系统 B 上运行），可从系统 A 上发出接管命令来执行角色切换：

db2 TAKEOVER HADR ON DATABASE foo_db

再次运行 connect 命令确认数据库在系统 A 上可访问：

db2 CONNECT TO foo_db

有关 TAKEOVER 命令的更多细节，参见 DB2 Version 10.5 Information Center 中的HADR 命令。

计划外事件接管

必须手动执行任何计划外故障转移；不支持自动灾难恢复接管。

从备用系统（系统 B）上发出以下命令：

db2 TAKEOVER HADR ON DATABASE foo_db BY FORCE

回页首

结束语

本文介绍了一个特定于 IBM PureData System for Transactions 的备用故障恢复解决方案的设置和操作。该解决方案基于 DB2 版本 10.5 中的 HADR 特性，利用了行业领先的 DB2 功能，同时解决了特定于 IBM PureData System for Transactions 的各方面问题。

回页首

致谢

作者希望对以下人员的意见、供稿、审阅和纠正表示衷心感谢：Diaa El-Din Ali、Marco Bonezzi、Paddy Burke、Yvonne Chan、Ciaran De Buitlear、Belarmino Fernandez、Brian McKeown、Nancy Miller、Andriy Miranskyy、Ryan Paton、Ismail Rawoof、Pablo Perez Rodriguez、Armin Tabrizi 和 Michael Zuliani。

回页首

附录 A：概念和术语

灾难恢复是指主数据系统发生灾难性损失时还原数据库操作。根据事件的严重程度以及中断是出于软件、网络、硬件还是整个套件故障，此数据损失的程度可能相差很大。

HADR 解决方案功能根据专用于备份的存储量、网络容量和归档日志策略进行定义。业务需求也是一个考虑事项：

RPO （恢复点目标）– 解决方案中的数据损失量。解决方案支持 ASYNC 和 SUPERASYNC 同步模式下的 HADR。这些同步模式的 RPO 值与 PureData System for Transactions 以外的其他系统的 RPO 值是相同的，即对于计划内事件是零数据损失，对于计划外事件是近零数据损失。
RTO （恢复时间目标）- 手动发起接管与应用程序连接到数据库之间经过的时间可以用秒/数据库来度量。这一时间不包括识别所发生问题与操作人员手动发起接管之间的时间。可以同时切换多个数据库。因此，一个完整的系统 RTO 也用秒度量。

HADR 设置包含一个通过 TCP/IP 连接连接到灾难恢复系统（可能在另一个城市）的主系统。当主系统上的数据库发生变更时，会不断从主数据库传送日志数据，并将其重新应用到备用系统上的一个数据库。这一流程不断更新备用数据库，支持快速接管操作。专用连接允许主备数据库维护不中断联系并建立复制状态。

备用系统是指在出现灾难性事件使主系统不可用时，为处理数据库灾难恢复操作而设置的 IBM PureData System for Transaction。

故障转移是指强制性地快速变更备用数据库的状态，使其成为主数据库，以维护数据可用性。这一状态变化应当仅在主数据库是非功能性数据库时发生。当 heartbeat 状态消息表明两个系统之间断开通信时，HADR 会报告故障，但故障转移并非绝对必须的。如果主系统发生故障，手动执行故障转移有助于预防任何不必要的服务中断。

接管是指非紧急或计划内情况下主备系统之间的角色变更。

故障恢复发生在一个接管操作之后。原始系统重新上线，恢复到原始状态。然后做一个角色变更来将当前 “故障转移” 主系统切换回其最初的备用角色。

回页首

附录 B：系统配置脚本

免责声明：这些程序并未在所有条件下作全面测试。它们由 IBM 提供，但 IBM 没有义务提供任何类型的支持。

IBM 按 “原样” 提供这些程序，不提供任何明示或暗示的担保，包括对称谓、非侵权性或干扰、适销性或特定用途的适用性的任何暗示担保。某些司法管辖区不允许排除或限制隐含的保证，因此上述限制或排除可能不适用于您。IBM 不承担因您使用、修改或分发这些程序或它们的派生产品而遭受的任何损失。

回页首

系统配置设置的验证

在 HADR 设置期间，数据库管理员需要搜集两个系统的实例和数据库配置设置以及注册表变量。仅在比较并更新了系统设置之后，才能在主备系统上启动 HADR。比较、对比和更新实例和数据库配置的这一过程比较费力，而且容易出错。

为了简化该任务，我们提供了 'as-is' Perl 脚本来执行以下任务：

连接到主系统（系统 A）和备用系统（系统 B）实例上的一个数据库
检索和比较实例和数据库配置和注册表变量
生成一个命令列表，调整系统 B 上的配置，使其与系统 A 配置保持一致。

该脚本必须在一个连接到 HADR 系统并且安装了 DB2 或 DB2 Connect 以及 Perl 语言副本的客户机上运行。DB2 和 Perl 可执行二进制代码必须在 $PATH 环境变量中。打开一个命令窗口并用命令运行脚本：

清单 3. 样例脚本

perl cfg_replicator.pl -ph <primary_host> -sh <secondary_host>     -in <instance_name> -pn <primary_host_portnumber>     -sn <secondary_host_portnumber> -db <database_name>     -u <username> -p <password> -d <update_direction>     -o <output_file_name>

其中脚本接受以下参数：

-ph <primary_host> 主系统主机（系统 A）的主机名或 IP 地址
-sh <secondary_host> 备用主机（系统 B）的主机名或 IP 地址
-in <instance_name> 实例名称
-pn <primary_host_portnumber> 主实例（系统 A 上）的端口号
-sn <secondary_host_portnumber>
备用实例（系统 B 上）的端口号
-db <database_name> 数据库名称
-u <username> 用户 ID（该用户必须拥有获取实例和数据库配置的权限）
-p <password> 用户 ID 的密码
-d <update_direction> “镜像” 语句的方向（ left 或 right ）。如果您将该值设置为 left ，脚本生成的命令是将备用系统（系统 B）配置设置为与主系统（系统 A）配置相同所需的命令。您将在该白皮书中概括的标准场景中使用这些命令。如果您想通过设置让主系统配置与备用系统配置相同，可以将参数设置为 right 来生成必要的命令。
-o <output_file_name>
输出文件的名称。该文件包含为统一配置而生成的命令。

除了这些参数，脚本还拥有以下参数：

-help ： 提供其他技术细节
-man ： 提供其他技术细节

脚本试图镜像所有配置参数。但是，一些参数（例如日志路径）可能在主系统与备用系统之间有所不同。在运行生成的命令之前查看脚本输出。

回页首

配置所有 HADR 设置

在 PureData System for Transactions 上配置和设置 HADR 的过程很复杂，而且一些任务的重复性使用户易出错。

包含该 'as-is' 脚本是为了辅助您完成以下任务：

为每个数据库更新 HADR 数据库配置参数
为每个数据库更新备用的服务器数据库配置
实现自动客户端重路由 (ACR)
在主备系统上启动 HADR
显示 HADR 设置的状态

该脚本有以下先决条件：

两个 DB2 版本 10.5 pureScale 实例（脚本适用于任何数量的成员）
主数据库经过配置，其中将 LOGARCHMETH1 设置为 TSM ，将 LOGINDEXBUILD 设置为 ON
使用已定义的这些参数对主数据库进行了备份。备份可以通过 Tivoli Storage Manager 完成，或手动使用标准 DB2 备份
主数据库可以接收新连接
两个实例拥有相同的实例用户
运行脚本的用户必须拥有 SYSAMD 或 SYSCTL 权限
创建的备用实例必须与主实例具有相同的实例名称
主系统必须有到备用系统的网络连接

对于该脚本，主成员是运行脚本所在的主系统上的成员。重播成员是在运行脚本时定义为参数的备用成员；该备用成员接收和处理从所有主成员收到的日志。

该脚本首先检查确认所有的先决条件都满足，然后才继续配置 HADR。脚本还检查主成员（从运行脚本的地方）与重播成员之间的基本连接。在检查完所有要求之后，脚本开始在备用实例、然后是主实例上进行 HADR 配置。备用数据库被配置为指向主数据库，反之亦然。

脚本中的下一步是激活和启动 HADR。在完成主要设置且每个成员上更新了数据库配置之后，脚本停用备用数据库，然后使用备用实例中的主要成员（重播成员）在备用系统上启动 HADR。在备用实例上启动 HADR 之后，脚本在主实例的每个成员上启动 HADR。

此时，HADR 开始将来自主数据库日志的所有日志信息同步到备用数据库日志。

配置中的最后一步是启用自动客户端重路由特性。该特性将更新每个成员上的可选服务器信息，这样一来当接管发生时，任何客户端连接都会被重定向到新的主系统。

在成功更新可选服务器设置之后，脚本验证配置结果并检查 HADR 设置的实际状态。此时，一切都应按预期启动和配置，所有主成员处于对等状态。

在主系统的第一个成员上从数据库所有者用户的主目录运行该脚本。该脚本必须由在创建数据库时指定的数据库所有者或拥有 SYSCTL 或 SYSADM 权限的用户运行。该用户在每个成员上都必须相同，且必须拥有同样的密码。

在将文件拷贝到主成员上的主目录之后，展开压缩文件：

tar –zxvf pdtx_hadr.tar.gz

在未压缩的 hadr 目录内，仔细阅读 README.txt 文件中的说明，然后使用以下命令运行脚本：

./pdtx_hadr_setup.sh -d <database> -s <standby_member> -a

在本教程中概述的示例场景中：

./pdtx_hadr_setup.sh -d foo_db -s 0 -a

其中脚本接受以下参数：

-d <database> 您想配置 HADR 的数据库
-s <standby_member>
备用成员。该成员是备用实例中的第一个成员（重播成员）
-a 应用配置。如果在不带 -a 参数的情况下调用脚本，它只将配置步骤写入脚本运行所在的成员上的 $HOME/hadr/cfg/ 中的配置文件中。如果指定了 -a ，脚本会应用所有配置更改，在主备数据库上启动 HADR，最后配置自动客户端重路由特性。