安装和配置说明

    下面一节介绍一个 3 节点的拓扑结构，如 图 1 所示。在这个示例中，有一个主动 - 被动式的 TSA 集群域，这个域由 2 个节点组成（Node1 和 Node2），它们共享一个存储，其中包含实际的 DB2 数据库文件和软件。这个拓扑结构中的第三个节点（Node3）由远程位置上的灾难恢复站点组成，它托管前面提到的主数据库的备用数据库。TSA 集群域和备用服务器通过专用线路链接在一起。这个 HADR 设置的主数据库名和备用数据库名是 jsbmain。

NODE1：主动 - 被动式的 TSA 集群域设置的机器之一。在当前的设置中，这个节点是主动节点，并拥有集群的资源。

NODE2：TSA 集群域设置的第二台机器。在当前的设置中，这个节点是被动节点，它作为集群的备用节点。

NODE3：这台机器是用于 DB2 故障恢复的 HADR 备用服务器，它不属于 TSA 集群域设置。 

    下面详细描述在 TSA 集群域中成功配置 DB2 HADR 的步骤。这个设置假设 TSA 集群域已经正确地设置好了。关于如何设置基本 TSA 集群域以及相关命令的更多信息，请参考 附录 A。

步骤 1：基本网络设置

1. 在每个节点的 /etc/hosts 文件中添加适当的 IP 地址到主机名映射。每个节点上的 hosts 文件应该像下面这样： 10.1.1.5 NODE1 10.1.1.6 NODE2 10.1.1.2 NODE3 2. 在每个节点上 ping 主机名或 IP 地址，确保这三个节点（例如，Node1、Node2 和 Node3）能够通过 TCP/IP 协议互相通信。 3. 在集群的所有节点（Node1 和 Node2）和备用机器（Node3）上，确保 /etc/services 文件中设置的 HADR 服务监听的端口是相同的。 在所有三台机器上，来自 /etc/services 文件的示例输出应该下面这样： DB2_HADR_15 55001/tcp DB2_HADR_16 55005/tcp 在这个示例中，DB2_HADR_15 是集群主节点上运行的 HADR 服务的名称，DB2_HADR_16 是备用服务器上运行的 HADR 服务的名称。

步骤 2：RSH 设置

注意：这个设置中使用的许多 TSA 命令要求在所有三个节点上设置 RSH。RSH 允许用户从一个节点上发出在另一个远程节点上执行的命令。关于在 Red Hat Linux 上设置 RSH 的更多信息，请参考本文的 参考资料 一节。

通过在 /root/.rhosts 文件中添加以下代码行来配置 RSH，从而允许根用户在每个节点（NODE1、NODE2 和 NODE3）上发出远程命令。 Node1 root Node2 root Node3 root 作为根用户登录，并在每个节点上发出以下命令： # rsh Node1 ls # rsh Node2 ls # rsh Node3 ls 应该会看到 NODE1、NODE2 和 NODE3 上 /root 的目录清单。

步骤 3：TSA 设置

    关于基本的 2 节点 TSA 集群域设置，请参考 附录 A。另外，在附录 A 中还有关于相关 TSA 命令的更多信息。

步骤 4：HADR 设置

注意：在这个设置中，数据库存储在外部共享存储 /jsbdata 中，这是一个 fastT600 光纤通道磁盘阵列。在集群的两台机器上，实例是不同的（尽管名称都是 db2inst1），但是数据库是相同的。DB2 附带的默认 TSA 脚本不支持主服务器和备用服务器（在 TSA 级）使用相同的名称。需要修改这些脚本来支持这个配置。 使用下面的编目命令在两个实例上注册数据库信息： db2 CATALOG DATABASE jsbmain AS jsbmain ON /JSBDATA

    从命令行处理程序（CLP）发出以下命令：

    在主数据库服务器（Node1）上：

db2 CONNECT RESET db2 UPDATE DB CFG FOR jsbmain USING INDEXREC RESTART LOGINDEXBUILD ON LOGARCHMETH1 "DISK: /jsbmain/ARCHFILES" LOGPRIMARY 100 LOGSECOND 50 LOGFILSIZ 5000 db2 BACKUP DATABASE jsbmain TO "/jsbmain/JSBBAK" WITH 2 BUFFERS BUFFER 1024 PARALLELISM 4 WITHOUT PROMPTING

    存储主服务器的备份的目录（/jsbmain/jsbbak）应该可以从备用服务器（Node3）访问，或者将它复制到备用服务器上的本地驱动器，这样恢复过程才能完成它。

注意：建议将备份文件复制到备用服务器上的本地驱动器，从而进行本地恢复，这是因为远程恢复要花更多的时间，因为恢复缓冲区必须通过网络传送。

    在备用服务器（Node3）上：

db2 RESTORE DATABASE jsbmain FROM "/jsbmain/JSBBAK" REPLACE HISTORY FILE WITHOUT PROMPTING

步骤 5：为自动客户机重路由配置数据库

    在主服务器（Node1）上，从 db2 CLP 执行以下命令，从而启用 HADR 的自动客户机重路由特性：

db2 UPDATE ALTERNATE SERVER FOR DATABASE jsbmain USING HOSTNAME 10.1.1.2 PORT 45000 这里的 10.1.1.2 是备用服务器（NODE3）的 IP 地址，45000 是备用服务器的 db2inst3 实例监听的端口号。 在备用服务器（NODE3）上，从 db2 提示执行以下命令，从而启用 HADR 的自动客户机重路由特性： db2 UPDATE ALTERNATE SERVER FOR DATABASE jsbmain USING HOSTNAME 10.1.1.1 PORT 50000

要点：当为备用服务器指定替代服务器的主机名时，应该确保指定 TSA 集群域的虚拟 IP 地址（在这个示例中，虚拟 IP 地址是 10.1.1.1）。 50000 是 db2inst1 实例监听的端口号。要确保 TSA 集群域的 Node2 和 Node1 上的 db2inst1 监听相同的端口。否则，在发生 HADR 故障恢复时，服务器 Node3 上的 db2inst3 会尝试与 db2inst1 的端口 50000 通信（在发生灾难时，db2inst1 不是主动的）。所有客户机应该至少连接主服务器一次，从而获得在发生灾难时使用的替代服务器信息。 要想了解关于 HADR 的自动客户机重路由特性的更多信息，请参考本文的 参考资料 一节。

步骤 6：更新 HADR 配置参数

    在集群的主动节点（在这个示例中是 Node1）的数据库上执行以下命令，让这个数据库成为 HADR 设置的主数据库：

db2 UPDATE DB CFG FOR jsbmain USING HADR_LOCAL_HOST 10.1.1.1 db2 UPDATE DB CFG FOR jsbmain USING HADR_LOCAL_SVC DB2_HADR_15 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_HOST 10.1.1.2 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_SVC DB2_HADR_16 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_INST DB2INST3 db2 UPDATE DB CFG FOR jsbmain USING HADR_SYNCMODE NEARSYNC db2 UPDATE DB CFG FOR jsbmain USING HADR_TIMEOUT 120 注意：应该特别注意，在 HADR 设置的主服务器的 HADR_LOCAL_HOST 中，一定要指定 TSA 集群域的虚拟 IP 地址，这样 HADR 才能在这个环境中正常发挥作用。

    在备用服务器（Node3）上执行以下命令，让这个数据库成为 HADR 设置的备用数据库：

db2 UPDATE DB CFG FOR jsbmain USING HADR_LOCAL_HOST 10.1.1.2 db2 UPDATE DB CFG FOR jsbmain USING HADR_LOCAL_SVC DB2_HADR_16 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_HOST 10.1.1.1 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_SVC DB2_HADR_15 db2 UPDATE DB CFG FOR jsbmain USING HADR_REMOTE_INST DB2INST1 db2 UPDATE DB CFG FOR jsbmain USING HADR_SYNCMODE NEARSYNC db2 UPDATE DB CFG FOR jsbmain USING HADR_TIMEOUT 120

    确保 TSA 域中的两个服务器和 备用服务器都为 DB2 通信启用了 TCPIP 协议。在 TSA 域的两个服务器以及备用服务器上，执行 db2set DB2COMM=TCPIP 命令。

步骤 7：启动 HADR

作为备用实例（db2inst3）的所有者，在备用节点（Node3）上启用 HADR，如下所示： db2 DEACTIVATE DATABASE jsbmain db2 START HADR ON DATABASE jsbmain AS STANDBY 作为主实例（db2inst1）的所有者，在主节点（Node1）上启用 HADR，如下所示： db2 DEACTIVATE DATABASE jsbmain db2 START HADR ON DATABASE jsbmain AS PRIMARY 注意：在启动 HADR 时，一定要先在备用服务器上启动 HADR 服务，然后在主服务器上启动。同样，在停止 HADR 时，要先在主服务器上停止服务，然后是备用服务器。

步骤 8：检查 HADR 设置

    现在，已经完成了 HADR 设置，就应该检查它是否能够正常工作。

    在主服务器（Node1）上执行以下命令：

db2 GET SNAPSHOT FOR DB ON jsbmain 
    输出应该像下面这样：

HADR Status Role = Primary State = Peer Synchronization mode = Nearsync Connection status = Connected, 11/24/2006 03:43:39.044650 Heartbeats missed = 0 Local host = 10.1.1.1 Local service = DB2_HADR_15 Remote host = jsbdr Remote service = DB2_HADR_16 Remote instance = db2inst3 timeout (seconds) = 120 Primary log position (file, page, LSN) = S0000139.LOG, 0, 000000003C8E0000 Standby log position (file, page, LSN) = S0000139.LOG, 0, 000000003C8E0000 Log gap running average (bytes) = 0

    在备用服务器（Node3）上执行以下命令：

db2 GET SNAPSHOT FOR DB ON jsbmain 

    备用服务器中的输出应该像下面这样：

HADR Status Role = Standby State = Peer Synchronization mode = Nearsync Connection status = Connected, 11/24/2006 03:41:59.782744 Heartbeats missed = 0 Local host = jsbdr Local service = DB2_HADR_16 Remote host = 10.1.1.1 Remote service = DB2_HADR_15 Remote instance = db2inst1 timeout (seconds) = 120 Primary log position (file, page, LSN) = S0000139.LOG, 0, 000000003C8E0000 Standby log position (file, page, LSN) = S0000139.LOG, 0, 000000003C8E0000 Log gap running average (bytes) = 0

步骤 9：测试 HADR 的故障恢复

    设置过程的最后一步是测试 HADR 的故障恢复功能。执行以下步骤：

a. 用 db2_kill 命令手工关闭主服务器。 b. 在备用服务器上执行接管命令。 db2 TAKEOVER HADR ON jsbmain c. 如果一般的接管不起作用，就需要指定 BY FORCE 选项，强迫 db2 切换到备用服务器上的 HADR。 d. 现在，像前面那样检查系统的状态，就会发现备用服务器正在起到主服务器的作用。状态可能要花一点儿时间才能反映，因为应用日志缓冲区时会有网络延迟，在此期间备用服务器会显示 Remote catch up pending 状态。

    现在，已经在 TSA 集群上设置了 DB2 HADR！！