通过 Tivoli Systems Automation 和 Reliable Scalable Cluster Technology 使用 DB2 High Availability Disaster Recovery

排除 DB2 高可用性集成解决方案中的故障

在 IBM DB2 9.5 for Linux, UNIX, and Windows 中引入的 IBM DB2 High Availability (HA) 特性,使数据服务器和集群管理软件之间的集成达到一个新的水平,它能提供统一的 High Availability Disaster Recovery (HADR) 自动框架。本教程将简要介绍该集成方案,您将会学到使用 DB2 和本解决方案的关键组成部分 Tivoli Systems Automation 时会用到的一些有用的诊断工具。让数据达到最高级别的性能和可靠性,同时知道如何排除故障,解决问题。

本教程的目标读者应对 HADR 有一定认识,但可能还不了解以下集成方案 — DB2 与 IBM Tivoli® Systems Automation (TSA) 和 IBM Reliable Scalable Cluster Technology (RSCT)。

Dipali Kapadia, DB2 后续工程软件开发人员, IBM China

Dipali Kapadia 的照片Dipali Kapadia 在 IBM 工作了四年。她目前就职于 DB2 Continuing Engineering for High Availability (HA) 部门,从事 HA 组件的生产问题和深入加强工作。Dipali 持有麦克玛斯特大学软件设计专业的工学学士学位。Dipali 以前也发表过 developerWorks 文章。



Michelle Chiu, DB2 后续工程软件开发人员, IBM China

Michelle ChiuMichelle Chiu 自 DB2 9.5 版本中引入集成解决方案起就在 DB2 Continuing Engineering HA 团队工作。她曾帮助客户实施这些解决方案并推动了众多的功能和服务能力改进。Michelle 持有滑铁卢大学计算机科学-生物信息学专业数学荣誉学士学位。



2011 年 1 月 06 日

DB2 High Availability 特性简介

在当今快节奏的世界里,时间就是金钱。更重要的是,停机时间就等于经济损失。这就是高可用性对所有企业,无论大小,都很重要的原因。高可用性数据库解决方案能够确保,万一数据库方案中某一部分宕机,可无缝切换到备份系统。尽管如此,没有集群管理,“切换” 就不能自动完成。系统管理员必须要走到数据服务器跟前,手动输入故障转移命令。这种场景下,就需要集成 HA 解决方案发挥作用了。

集成 HA 解决方案,又称为 DB2 High Availability 特性,是在 DB2 9.5 中引入的。在此方案中,集群管理器 Tivoli Systems Automation / Reliable Scalable Cluster Technology (TSA/RSCT) 与 DB2 for Linux, UNIX, and Windows Workgroup Edition and Enterprise Edition 捆绑在一起。它负责监控所有的数据库资源,并在发生故障时发出合适的动作。集成解决方案的主要优势有:

  • 它很简单:DBA 不需要再学习新的集群管理器命令来管理资源。
  • 它是集成的:DB2 使用 db2haicu 工具与 TSA 无缝集成,可触发适当的动作。DB2 与 TSA/RSCT 捆绑在一起。当应用 DB2 补丁包后,补丁包会根据需要自动打上重要的 TSA/RSCT 补丁,升级 TSA/RSCT。

在典型的集成 HA 解决方案配置中,两个主机上都安装 TSA/RSCT。它负责监控如网络接口、DB2 实例、HADR 数据库这样的实体。客户端使用一个虚拟 IP 地址,通过公共网络连接到主系统数据库。如果主系统主机发生错误,虚拟 IP 地址就切换到备用机上。从用户角度,感觉不到停机,因为转换是自动完成的。如果每个主机上有两个网络接口,可以设置专门的网络用于 HADR 复制。

图 1. 集成 HA 解决方案
用户通过公共网络连接到主网络和备用服务器,它们又通过专用网络相互连接,用于 HADR 复制

前提条件

使用 TSA/RSCT 的集成 HA 解决方案可用于 Linux 和 AIX 上的 DB2 9.5 for Linux, UNIX, and Windows 或更新版本,以及 Solaris 上的 V9.7 或更新版本。


DB2 和 TSA/RSCT 中的诊断工具

本节介绍了 DB2 和 TSA/RSCT 中的一些工具,它们可用来识别和排除集成 HA 环境中可能会发生的故障。经验丰富的 DBA 或 TSA/RSCT 用户可能已经很熟悉这些工具了。尽管如此,只使用这些工具就能缩小范围并识别潜在的问题了。本节将讲解每个工具在 HA 架构中发挥的作用。

DB2 工具

数据库配置参数

要取得数据库对(主服务器和备用服务器)的 HADR 相关参数,在每个主机上运行以下命令:

db2 get db cfg for <dbname> | grep HADR

清单 1 显示了输出样例。

清单 1. HADR 相关配置参数的输出
(db2inst1@host1) /home/db2inst1 $ db2 get db cfg for HADRDB | grep HADR            
 HADR database role                                      = STANDARD
 HADR local host name                  (HADR_LOCAL_HOST) = host1
 HADR local service name                (HADR_LOCAL_SVC) = 50001
 HADR remote host name                (HADR_REMOTE_HOST) = host2
 HADR remote service name              (HADR_REMOTE_SVC) = 50002
 HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
 HADR timeout value                       (HADR_TIMEOUT) = 120
 HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC
 HADR peer window duration (seconds)  (HADR_PEER_WINDOW) = 300

HADR 数据库角色 是数据库的实际角色。它的可能值有 PRIMARY、STANDBY 和 STANDARD。有个好方法,将它与 lssam(一个 TSA/RSCT 命令)的输出对比,确认数据是否一致。表 1 显示了 lssam 的输出如何映射到 HADR 数据库角色。

表 1. HADR 角色到 OpState 映射
HADR 数据库角色来自 lssam 的 HADR 资源 OpState
PrimaryOnline
StandbyOffline
StandardOffline

db2haicu 工具使用这些参数值生成集群资源名称。同样,在检查资源是否在集群中已存在时也会用到这些值。在解决设置方面的故障时要特别注意这些配置。

除了 HADR 参数以外,db2haicu 工具还有一些命名方面的要求。表 2 总结了命名要求。

表 2. 命名限制
DB 参数HADRdb2haicu
HADR_LOCAL_HOST名称要能被解析成主机名(例如,缩写名、符合条件的域名、IP 地址、别名) 缩写名;符合条件的域名(V95FP5 中的 LI74662 、V97FP1 中的 IC62233)
HADR_REMOTE_HOST名称要能被解析成主机名(例如,缩写名、符合条件的域名、IP 地址、别名) 缩写名;符合条件的域名(V95FP5 中的 LI74662 、V97FP1 中的 IC62233)
HADR_REMOTE_INST不区分大小写区分大小写
HADR_PEER_WINDOW大于等于 0大于 0

db2pd 工具

工具可以按以下方式运行:

db2pd hadr db <name>

清单 2 显示了输出样例。

清单 2. db2pd 输出
(db2inst1@host2) /home/db2inst1$ db2pd hadr db hadrdb

Database Partition 0 -- Database HADRDB -- Standby -- Up 0 days 00:16:44 -- 
Date 08/04/2010 17:08:05

HADR Information:
Role    State                SyncMode HeartBeatsMissed   LogGapRunAvg (bytes)
Standby RemoteCatchup        Sync     0                  365349536

ConnectStatus ConnectTime                           Timeout
Connected     Wed Aug  4 16:51:22 2010 (1280955082) 120

PeerWindowEnd                         PeerWindow
Null (0)                              300

LocalHost                                LocalService
host2                                    50002

RemoteHost                               RemoteService      RemoteInstance
host1                               	 50001              db2inst1

PrimaryFile  PrimaryPg  PrimaryLSN
S0029674.LOG 0          0x000000001F060B7B

StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
S0008608.LOG 0          0x000000000A8D3EE1 2%

db2pd 工具直接访问 DB2 系统存储状态。这是数据库的正确角色。在某些错误情况或时间敏感的场景下,集群管理器看到的数据库可能与数据库本身看到的不一样。用这个工具确认实际状态是一种很好的做法。

db2diag.log

此日志一般保存在 ~/sqllib/db2dump/db2diag.log 目录下。可以使用 DIAGPATH 数据库管理器配置参数来配置该存储位置。

该日志是 DB2 实例和数据库主要诊断日志。它可分不同通知级别(info/warning/error/severe)记录诊断消息。此日志的默认级别是 3(警告)。日志级别可通过 DIAGLEVEL 设置来调整。在排除可重现故障时,有个好方法是将 DIAGLEVEL 改成 4,获取最多数据。

db2 update dbm cfg using DIAGLEVEL 4

通过查看 db2diag.log 可以看到 HADR 角色历史、db2haicu 与集群管理器的相互调用,以及一些集群管理器错误消息。运行 db2diag h,筛选并格式化日志。

与 db2haicu 和集成 HA 代码相关的消息冠以前缀 'sqlha'。由于集成解决方案在底层隐式调用 TSA/RSCT,有些错误会直接绕过集群管理器。这些错误会用特殊语法(### --- ####-###)存入 db2diag.log。####-### 是 RSCT 错误代码。可以在 RSCT 信息中心查找这些错误(见 参考资料)。

如果能区分是哪里产生问题,这将帮助 IBM Support 将注意力集中到出问题的模块上。

清单 3 显示了 db2diag.log 输出的样例。

清单 3. db2diag.log 输出
2010-07-28-09.54.04.342244-240 E1753286A844       LEVEL: Error
PID     : 589910               TID  : 1           PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaDeleteResourceGroup, pro
be:300
MESSAGE : ECF=0x90000548=-1879046840=ECF_SQLHA_DELETE_GROUP_FAILED
          Delete group failed
DATA #1 : String, 35 bytes
Error during vendor call invocation
DATA #2 : unsigned integer, 4 bytes
30
DATA #3 : String, 29 bytes
db2_db2inst1_db2inst1_HADRDB-rg
DATA #4 : unsigned integer, 8 bytes
1
DATA #5 : signed integer, 4 bytes
8
DATA #6 : String, 101 bytes
Line # : 7650---2621-008 Failed to update resource because of configuration 
data replication errors.
DATA #7 : Object [PD_TYPE_STRING] not dumped
Address: 0x00000001100A90FD Size: 0 Reason: Zero-length data

输入以下命令可很快看到 HADR 角色变化顺序:

cat db2diag.log | grep i "hadr state"

清单 4 和 5 显示了两个服务器的输出。

清单 4. 主服务器上 db2diag.log 中 HADR 状态的输出结果
CHANGE  : HADR state set to None (was None)
CHANGE  : HADR state set to P-Boot (was None)
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Boot)
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Peer)
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)
清单 5. 备用服务器上 db2diag.log 中 HADR 状态的输出结果
CHANGE  : HADR state set to None (was None)
CHANGE  : HADR state set to S-Boot (was None)
CHANGE  : HADR state set to S-LocalCatchup (was S-Boot)
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-LocalCatchup)
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-RemoteCatchupPending)
CHANGE  : HADR state set to S-RemoteCatchup (was S-RemoteCatchupPending)
CHANGE  : HADR state set to S-NearlyPeer (was S-RemoteCatchup)
CHANGE  : HADR state set to S-Peer (was S-NearlyPeer)

db2support 工具

这个工具从 DB2 实例环境和操作系统收集详细信息。对于 HADR 问题,一般应该运行带 -d 标记的 db2support 来收集数据库相关信息。IBM 支持人员将在必要时提供使用指导。

TSA/RSCT 工具

用户收集的大多数数据都是 DB2 相关的,而必要的 TSA/RSCT 数据会丢失。本节将讲解如何获取相关的 TSA/RSCT 信息来帮助您深入了解为何集群管理器以这种方式工作。

lssam 命令

lssam 命令用来获取集群资源状态快照。图 2lssam 解释)剖析并讲解了此命令的典型输出样例。每个资源组都有一个名义上的状态 — 想要的状态。一个资源组包含一个或多个资源组成员,每个资源组包含一个或多个资源。在图 2 中,显示了三个资源组 — 一个用于本地实例,一个用于远程实例,一个用于 HADR 数据库。资源 OpState 是资源的实际状态,资源类是资源所属的 TSA 类。资源名称还包含主机名,资源可能在此主机上运行。

图 2. lssam 解释
lssam 输出样例的屏幕截图,附有剖析讲解

TSA/RSCT 通过在设定的时间间隔内运行各种 DB2 脚本来监控 DB2 实例和数据库行为。脚本的位置是 HADR 对中两个主机的 /usr/sbin/rsct/sapolicies/db2 目录下。对于此解决方案,有 6 个主要脚本。这些脚本使用名为 db2gcf 的 DB2 工具与实例和 HADR 数据库集成。在 DB2 信息中心可查看关于 db2gcf 的详细信息(见 参考资料 链接)。

每个脚本的名称都包含当前 DB2 版本。本教程使用 V9.7。

实例监控脚本(db2V97_monitor.ksh)

实例监控脚本负责监控实例状态。默认情况下,HADR 对节点上的 TSA/RSCT 会在 HADR 对节点对上的主机上,在指定的时间间隔调用它。实例资源的 OpState 在此基础上升级。在 图 2 中,实例资源是 db2_db2inst1_host1_0-rs 和 db2_db2inst1_host2_0-rs。

表 3. 实例监控脚本返回代码
OpState脚本返回代码含义(DB2 角度)
Online1实例已启动。
Offline2实例未启动,或获取状态时发生错误。

实例启动脚本(db2V97_start.ksh)

实例启动脚本负责 DB2 实例并激活数据库。如果需要,启动脚本也可以执行重新集成。

实例停止脚本( db2V97_stop.ksh)

实例停止脚本负责停止实例。它专门用于各台主机发生问题时停止实例。

HADR 监控脚本(hadrV97_monitor.ksh)

HADR 监控脚本负责监控 HADR 数据库状态。默认情况下,HADR 对中两个主机上的 TSA/RSCT 每隔 29 秒调用此脚本。HADR 资源的 OpState 在此基础上升级。在 图 2 中,HADR 资源是 db2_db2inst1_db2inst1_HADRDB-rs。

表 4. HADR 监控脚本返回代码
OpState脚本返回代码含义(DB2 角度)
Online1HADR 是主系统。
Offline2HADR 是备用系统,或获取状态时发生错误。

HADR 启动脚本(hadrV97_start.ksh)

HADR 启动脚本负责启动现有备用数据库上的 HADR,并让它承担主系统角色。

HADR 停止脚本(hadrV97_stop.ksh)

HADR 停止脚本负责停止 HADR。它专门用于在各台机发生问题时停止实例。

系统日志

系统日志显示 TSA/RSCT 资源管理历史。如果出现某些类型的 TSA/RSCT 错误,也显示在其中。将系统日志和 db2diag.log 联合分析,可以了解故障场景中事件发生顺序。

在 Linux 系统中,系统日志位于 /var/log/messages/syslog.out 目录。

在 AIX 系统中,系统日志位于 /tmp/syslog.out 目录。

系统设置不同,系统日志位置不同。可在 /etc 下的 syslog.conf 中修改其位置。

当与 db2diag.log 联合使用时,系统日志就成为功能强大的调试工具。交叉比较两个日志中的关键时间戳能有效帮助重建错误场景中的事件顺序。

例如,清单 6 显示某一实例在 22:05:44 左右被终止。

清单 6. 被终止的实例
db2inst1@host1:~> date
Wed Aug  4 22:05:44 EDT 2010
db2inst1@host1:~> db2_kill
ipclean: Removing DB2 engine and client's IPC resources for db2inst1.

TSA/RSCT 应该调用了启动脚本。看看系统日志中 22:05:44 左右的内容确认一下。

清单 7. 启动脚本
Aug  4 22:05:53 host1 db2V97_start.ksh[9540]: Entered /usr/sbin/rsct/sapolicies/db2
                      /db2V97_start.ksh, db2inst1, 0
Aug  4 22:05:53 host1 db2V97_start.ksh[9541]: Able to cd to /home/db2inst1/sqllib : 
                      /usr/sbin/rsct/sapolicies/db2/db2V97_start.ksh, db2inst1, 0
Aug  4 22:05:53 host1 db2V97_start.ksh[9551]: 1 partitions total: /usr/sbin/rsct
                      /sapolicies/db2/db2V97_start.ksh, db2inst1, 0
Aug  4 22:06:00 host1 db2V97_start.ksh[9774]: Returning 0 from /usr/sbin/rsct
                      /sapolicies/db2/db2V97_start.ksh ( db2inst1, 0)

实例成功启动。看看 db2diag.log 中 22:06:00 左右的内容确认一下。

清单 8. 实例已启动
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

TSA/RSCT 应该调用了 HADR 启动脚本。看看系统日志中 22:06:00 左右的内容确认一下。

清单 9. HADR 启动脚本
Aug  4 22:06:14 host1 /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh[9948]: ...returns 0
Aug  4 22:06:14 host1 /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh[9949]: Returning 0
                      : db2inst1 db2inst1 HADRDB

HADR 一旦启动,它就试图达到 PEER 状态。看一下 db2diag.log 中 22:06:00 左右的内容,查找关键词 “HADR state”。

清单 10. 验证 HADR PEER 状态
2010-08-04-22.06.01.254052-240 E11446E359          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to None (was None)

2010-08-04-22.06.01.256495-240 E12922E361          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-Boot (was None)

2010-08-04-22.06.01.964755-240 E14817E379          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Boot)

2010-08-04-22.06.03.184782-240 E22305E388          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)

2010-08-04-22.06.03.304770-240 E23429E378          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)

2010-08-04-22.06.03.317330-240 E23808E369          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)

lsrsrc

还有其他的 TSA/RSCT 命令可用来显示资源的特定属性。lsrsc 是个很有用的命令,可用来了解属于某个特定资源类的各种资源的内部工作原理。最常用的类是 IBM.Application、IBM.ServiceIP 和 IBM.Test。这些类由 TSA/RSCT 创建,可用作其他产品与集群管理器交互的接口。

集群资源

一般情况下,集群资源属于 IBM.Application。集群资源用来表示如 DB2 实例或 HADR 数据库这样的实体。当 db2haicu 运行时,它使用 TSA/RSCT 命令创建这些资源。每个集群资源都有很多属性。startstopmonitor 命令属性与 DB2 脚本绑定,这在 “lssam 命令” 一节中已经探讨。这就是 TSA/RSCT 如何知道调用什么来管理资源的方法。

此工具可以按以下方式运行:

lsrsrc -s "Name like 'db2_db2inst1%" IBM.Application
清单 11. 运行工具
db2inst1@host1:~> lsrsrc -s "Name like 'db2_db2inst1_db2inst1_HADRDB-rs' AND 
                  NodeNameList={'host1'}" IBM.Application
Resource Persistent Attributes for IBM.Application
resource 1:
Name                  = "db2_db2inst1_db2inst1_HADRDB-rs"

ResourceType 	         = 0
AggregateResource     = "0x2028 0xffff 0xa5530134 0xe14e5051 0x91c6ee58 
                         0xa6a94e38"
StartCommand          = "/usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh 
                         db2inst1 db2inst1 HADRDB"               
StopCommand           = "/usr/sbin/rsct/sapolicies/db2/hadrV97_stop.ksh 
                         db2inst1 db2inst1 HADRDB"
MonitorCommand        = "/usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh 
                         db2inst1 db2inst1 HADRDB"
MonitorCommandPeriod  = 21
MonitorCommandTimeout = 29
StartCommandTimeout   = 330
StopCommandTimeout    = 140
UserName              = "root"
RunCommandsSync       = 1
ProtectionMode        = 1
HealthCommand         = ""
HealthCommandPeriod   = 10
HealthCommandTimeout  = 5
InstanceName          = ""
InstanceLocation      = ""
SetHealthState        = 0
MovePrepareCommand    = ""
MoveCompleteCommand   = ""
MoveCancelCommand     = ""
CleanupList           = {}
CleanupCommand        = ""
CleanupCommandTimeout = 10
ProcessCommandString  = ""
ResetState            = 0
ReRegistrationPeriod  = 0
CleanupNodeList       = {}
MonitorUserName       = ""
ActivePeerDomain      = "hadr_domain"
NodeNameList          = {"host1"}

标记资源

标记资源属于 IBM.Test 类。标记资源本质上是临时的。它们由 DB2 代码生成,用于与 TSA 持续通讯。通讯动作结束后应自动清除。如果标记还留着,说明发生了错误。标记由新的主数据库创建,用于通知旧的主服务器它应该 “重新集成”自己,其含义是应当将其角色转换成备用。检查标记是调试的好方法;尽管如此,在正常场景下,却不必监控它。

此工具可以按以下方式运行:

lsrsrc IBM.Test
清单 12. 运行工具
db2inst1@host2:~> lsrsrc IBM.Test
Resource Persistent Attributes for IBM.Test
resource 1:
        Name              = "db2_HADRDB_host1_Reintegrate_db2inst1_db2inst1"
        ResourceType      = 0
        AggregateResource = "0x3fff 0xffff 0x00000000 0x00000000 0x00000000    
                             0x00000000"
        ForceOpState      = 0
        TimeToStart       = 0
        TimeToStop        = 0
        WriteToSyslog     = 0
        MoveTime          = 0
        MoveFail          = 0
        ForceMoveState    = 0
        ActivePeerDomain  = "hadr_domain"
        NodeNameList      = {"host2"}

getsadata

它等同于 TSA/RSCT 角度的 db2support。要获取最多数据,运行带有 all 标记的 getsadata。此工具必须作为根用户运行。IBM Support 可给予这方面指导。


故障处理

很多时候,用户会遇到故障,但到他们打开 PMR 的的时候,却已经失去了收集特定时间和场景数据的机会。本节的目的是帮助您识别可能会遇到的故障种类,以便能收集合适的诊断信息。这能够帮助 IBM Support 更高效地解决问题。某些情况下,甚至您自己就可以解决问题。

研究了前几年客户遇到的问题之后,我们总结出四种主要的问题类别:

以下小节将详细讲解以上各类。

意外的故障转移

在意外的故障转移中,主系统上发生了不应导致备用系统接管的事件。但是,却发生了故障转移,造成了潜在的数据丢失和中断。

要考虑的方面:

  • 方案是按照预先设计运行的吗?
    • 会发生故障转移的场景:
      • 主系统宕机(例如,断电)
      • 主系统公共网络故障
      • 主系统实例故障
  • 不会发生故障转移的场景:
    • 终止实例(例如,db2_kill)
    • 专用网络故障
  • 为什么会发生故障转移?
    • HADR 数据库资源的原有状态不是主系统
    • 实例和 HADR 启动脚本未调用
    • 实例和 HADR 启动脚本不成功

考虑 HADR 数据库资源的原有角色

TSA/RSCT 保证 HADR 资源在一个主机上在线(主系统),在另一个主机上离线(备用系统)。如果情况不是这样,有可能产生的意外故障转移是 TSA 试图确保资源在可用主机上在线。有几种方法检查 HADR 数据库角色:

  • 检查原始主系统上的 db2diag.log。(见 “db2diag.log” 一节中详细信息。)HADR 开始时的状态是主系统吗?直到故障转移事件发生,它一直是这个状态吗?
  • 检查原始主系统上的数据库配置参数。(见 “数据库配置参数” 一节。)数据库角色是什么?它与 lssam 数据库资源 OpState 匹配吗?
  • 检查原始主系统上的 db2pd 输出。(见 “db2pd 工具” 一节中详细信息。)数据库角色是什么?它与 lssam 数据库资源 OpState 匹配吗?

原始角色是主系统,那现在呢?

必须要考虑的第一个,也是最明显一个问题是:调用了启动脚本吗?一定要记住,如果实例终止了,它的 HADR 数据库应该也不可用了。因此,TSA/RSCT 应该同时调用实例和 HADR 启动脚本。如果 HADR 数据库变得不可用,那么也应该调用 HADR 启动脚本。

  • 打开原始主系统上的系统日志。
  • 看到脚本调用了吗?
    • 是 - 继续调试。
    • 否 - 这非常可疑。如 “系统日志” 一节中所述,系统日志中有 TSA 的资源管理历史。应该看到特定的时间间隔内调用监控脚本。问问自己,“集群配置正确吗?日志是否启用,级别正确吗?”
  • 看到启动脚本调用了吗?查找监控脚本 “Returning 2”。紧接着之后,应该是实例启动脚本。
    • 是 - 继续调试。
    • 否 - 与 TSA/RSCT 问题类似。联系 IBM Support。
  • 启动脚本成功返回了吗(换句话说,有 “Returning 0” 吗)?
    • 是 - 这意味着实例正确启动。尽管如此,紧接着发生的事件会导致故障转移。看看 db2diag.log 中该时间段附近是否有其他错误。

db2 激活故障

实例启动之后,必须激活数据库以使复制过程继续进行。激活不一致的数据库会产生故障。如果实例损坏(例如,用 db2_kill 终止实例),数据库就会不一致。如果数据库启用 AUTORESTART,就会触发重启,并执行损坏恢复,返回的数据库状态不一致。

  • 检查 AUTORESTART 是否启用,试着手工激活。
    db2 get db cfg for <database> | grep AUTORESTART
    db2 activate db <database>

db2gcf 超时

实例启动脚本使用 db2gcf 工具来启动实例。如果 db2gcf 超时,会看到 db2diag.log 消息有指示。

清单 13. db2diag.log 消息
2010-06-05-02.05.33.824563-240 I18731842A257      LEVEL: Error 
PID     : 1831554              TID : 1 
FUNCTION: DB2 Common, Generic Control Facility, GcfCaller::start, probe:40 
MESSAGE : ECF=0x9000028C Timeout occured while calling a GCF interface function

试着手工启动实例,看看需要多长时间(db2start)。

试着不设定超时,使用 db2gcf 启动实例,看看要多长时间。启动时间根据具体环境中的分区数不同而不同;但是,每个分区应该在数秒以内。

db2gcf u i <instance>

db2start 故障

如果实例成功启动,db2diag.log 中肯定会有相关指示的消息。

清单 14. db2diag.log 消息
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

手工启动实例,看看是否成功。

TSA/RSCT 错误

DB2 通过发布 TSA/RSCT 命令与集群管理器交互。如果这些命令不成功,db2diag.log 中就会有相应的条目提示。(见 “db2diag.log” 一节中详细信息。)

角色不是主系统,那是什么?

这里的主要问题是原有角色为什么不是主系统?是否发生了更大的问题?

当使用 db2haicu 集群化一个实例,就会创建 TSA/RSCT 资源,同时还有两者之间的依赖关系。可用 lsrel 命令查看集群之间的依赖关系。

可按以下方式运行工具:

lsrel -Ab
清单 15. lsrel 命令
db2inst1@host1:~> lsrel -Ab
Displaying Managed Relationship Information:
All Attributes

Managed Relationship 1:
        Class:Resource:Node[Source] = IBM.Application:db2_db2inst1_host1_0-rs
        Class:Resource:Node[Target] = {IBM.Equivalency:db2_public_network_0}
        Relationship                = DependsOn
        Conditional                 = NoCondition
        Name                        = db2_db2inst1_host1_0-
                                      rs_DependsOn_db2_public_network_0-rel
        ActivePeerDomain            = hadr_domain
        ConfigValidity              =

实例资源与公共网络之间就是依赖关系的一个例子。如果公共网络失效,客户端就连接不到数据库,就会发生故障转移。此时就要检查公共网络是否可用。

下一步

如果看完本节,问题还没解决,那最好打开 PMR。根据以上指导将所有发现描述清楚。此外,还应加入以下内容:

  • 手工运行的命令的输出结果
  • db2support
  • getsadata

未发生故障转移

本节将讲述如何解决应该发生故障转移却未发生的情况。进一步诊断前,应先问自己几个问题:

  • 故障转移应该发生吗?
    • 我们认为应该发生故障转移的场景有:
      • 主系统宕机(例如,断电)
      • 主系统网络故障
      • 主系统实例故障
  • 我们认为不应发生故障转移的场景有:
    • 终止实例(例如,. db2_kill)
    • 专用网络故障
  • 如果应该发生故障转移却没发生,那究竟发生了什么?
    • 未检测到故障,因此无响应
    • 检测到故障,但故障转移未启动
    • 故障转移启动,但未成功

为了选择正确的分类,先回顾一下在故障时 TSA/RSCT 会采取的动作。

有个误解,只要主系统出现故障,就会发生故障转移。并非总是如此。如果主系统可以迅速恢复,就不一定要故障转移。首先,TSA/RSCT 会试着在同一主机上重启实例、HADR 数据库,或两者同时重启。如果失败,它会启动备用主机上的 HADR 数据库。

例如,如果 db2sysc 进程被终止,但 HADR 主数据库能在指定时间内重启,就不会发生故障转移。但是,在故障延时场景中(例如,实例不能恢复或重启时间过长),就会发生故障转移。

检测到故障了吗?

集群资源是通过调用其监控脚本并检查其返回代码来监控的。应当查看故障时间附近资源监控脚本返回代码的变化。

  • 打开原始主系统主机上的系统日志。
  • 看到 HADR 监控脚本条目了吗?
    • 是 - 继续调试。
    • 否 - 正确设置时,应当定时运行监控脚本以监控 HADR 数据库资源的状态。日志是否启用?其级别是否正确?确认集群域是否配置正确。

提示

可以搜索实例监控脚本 “Returning 2”,找到检测到 DB2 实例的时间点。

  • 浏览 HADR 监控脚本条目,查找返回代码从 “Returning 1” 变成 “Returning 2” 的时间。看到变化了吗?
    • 是 - 这就是 TSA/RSCT 首次检测到主数据库故障的时间。故障检测正确。 到下一个问题 “故障转移启动了吗?”
    • 否 - 继续调试。
  • 看到超时错误了吗?
    • 是 - 监控脚本获取集群管理器资源状态的时间过长。在详细模式下运行脚本,看看是否耗时过长或脚本挂起。
      清单 16. 详细模式下运行脚本
      root@host2:/usr/sbin/rsct/sapolicies/db2# 
      ./hadrV97_monitor.ksh db2inst1 db2inst1
      HADRDB verbose
      + CT_MANAGEMENT_SCOPE=2
      + export CT_MANAGEMENT_SCOPE
      + CLUSTER_APP_LABEL=db2_db2inst1_db2inst1_HADRDB
      + [[ verbose == verbose ]]
      + typeset +f
      + typeset -ft main monitorhadr set_candidate_P_instance
      + main db2inst1 db2inst1 HADRDB verbose
      + set_candidate_P_instance
      + candidate_P_instance=db2inst1
      + candidate_S_instance=db2inst1
      + + hostname
      + tr .
      + awk {print $1}
      localShorthost=host2
      + [[ db2inst1 != db2inst1 ]]
      + return 0
      + + lsrsrc -s Name = 'db2_HADRDB_host2_Reintegrate_db2inst1_db2inst1' 
      IBM.Test Name
      + grep -c Name
      nn=0
      + [[ 0 -eq 0 ]]
      + [[ db2inst1 != db2inst1 ]]
      + [[ 0 -ne 0 ]]
      + monitorhadr
    • 否 - 如果监控脚本总是 “Returning 1”,TSA/RSCT 会认为资源仍然在线,不会采取动作。
      • 它与 DB 2 方面的状态匹配吗?
      • 检查 db2diag.log,根据 db2pd 看看数据库实例运行状况以及最后一次 HADR 角色改变。

故障转移启动了吗?

在故障转移应该会发生的场景中(例如,原始主机上的资源无法启动),一旦检测到故障,就应该进行故障转移。对于 DB2 HADR 资源,这意味着要在原始备用主机上调用 HADR 启动脚本。

  • 打开原始备用主机上的系统日志。
  • 注意相关时间范围。
  • 看到脚本调用了吗?
    • 是 - 继续调试。
    • 否 - 这很可疑。要看看系统日志中某一时间间隔调用的监控脚本。问问自己,“集群配置是否正确?是否启用了系统日志?”
  • 看到 HADR 启动脚本调用了吗?
    • 是 - 这意味着 TSA/RSCT 试图在备用主机上启动资源。到目前为止,这都是正确的行为。到下一个问题 “故障转移成功了吗?”
    • 否 - 这和 TSA/RSCT 问题类似。联系 IBM Support。

故障转移成功了吗?

提示

可以通过查看 db2diag.log 来确认 HADR 数据库状态。查找关键词 “HADR state” 来查看到主系统的转换。

  • HADR 启动脚本返回成功了吗(换句话说,有 “Returning 0” 吗)?
    • 是 - 这意味着在原始备用主机上,数据库作为主系统启动。

      查看 lssam 此时的输出,应该会看到角色转换,此时原始备用主机上的 HADR 数据库资源在线,而原始主系统主机离线。

      清单 17. lssam 输出
      root@host1:/# lssam
      Online IBM.ResourceGroup:db2_db2inst1_host1_0-rg Nominal=Online
              '- Online IBM.Application:db2_db2inst1_host1_0-rs
                      '- Online IBM.Application:db2_db2inst1_host1_0-rs:host1
      Failed offline IBM.ResourceGroup:db2_db2inst1_host2_0-rg Nominal=Online
              '- Failed offline IBM.Application:db2_db2inst1_host2_0-rs
                      '- Failed offline IBM.Application:db2_db2inst1_host2_0-rs:host2
      Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg 
      Control=MemberInProblemState 
      Nominal=Online
              '- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
                 Control=MemberInProblemState
                      |- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:host1
                      '- Failed offline 
                      IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:host2
      Online IBM.Equivalency:db2_db2inst1_host1_0-rg_group-equ
              '- Online IBM.PeerNode:host1:host1
      Online IBM.Equivalency:db2_db2inst1_host2_0-rg_group-equ
              '- Online IBM.PeerNode:host2:host2
      Online IBM.Equivalency:db2_db2inst1_db2inst1_HADRDB-rg_group-equ
              |- Online IBM.PeerNode:host2:host2
              '- Online IBM.PeerNode:host1:host1

      继续排除故障。接管确实成功完成,因此后来一定发生了什么,造成明显故障,从而导致故障转移。浏览系统日志条目,形成事件序列。

      注意:看看 HADR 监控脚本返回代码。它们一开始就返回 1 后来返回 2,还是超时?如果 HADR 监控脚本后来返回 2,那就发生了第二次故障。在 db2diag.log 中确认。

    • 否 - 使用 HADR 启动脚本,TSA/RSCT 不能在备用主机上启动数据库作为主系统。查看 db2diag.log 进一步诊断。反复用系统日志中的时间戳与 db2diag.log 文件中的时间戳对比。HADR 启动脚本失败的时间范围内,db2diag.log 中有没有错误消息?我们看看一些可能的根本原因。

Peer 窗口过期

如果 HADR_PEER_WINDOW 配置参数过小,那么它可能在集群管理其发布从备用系统接管命令前就过期。在以下的清单 18 中,HADR_PEER_WINDOW 设置为 5。

清单 18. 备用 db2diag.log
2010-08-05-10.30.21.185557-240 I609665A427        LEVEL: Severe
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20215
RETCODE : ZRC=0x8280001B=-2105540581=HDR_ZRC_COMM_CLOSED
          "Communication with HADR partner was lost"

2010-08-05-10.30.21.185758-240 E610093A373        LEVEL: Event
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to S-DisconnectedPeer (was S-Peer)

2010-08-05-10.30.21.186057-240 I610467A356        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrCloseConn, probe:30595
MESSAGE : Peer window end time :1281018623



2010-08-05-10.30.24.198297-240 I612083A367        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20202
MESSAGE : Peer window ends. Peer window expired.

2010-08-05-10.30.24.198729-240 E612451A389        LEVEL: Event
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-DisconnectedPeer)

在 TSA/RSCT 检测到主数据库故障并准备接管之前,对等窗口已经过期。这就会导致 HADR 启动脚本失败。

清单 19. 备用系统日志
Aug  5 10:31:15 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh 
                                  [663766]: Returning 2 : db2inst1 db2inst1 HADRDB
Aug  5 10:31:17 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [692326]: Returning 1 (db2inst1, 0)
Aug  5 10:31:27 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [471160]: Returning 1 (db2inst1, 0)
Aug  5 10:31:34 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh
                                  [471162]: Entering : db2inst1 db2inst1 HADRDB
Aug  5 10:31:36 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh
                                  [598066]: Entering : db2inst1 db2inst1 HADRDB
Aug  5 10:31:37 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [700494]: Returning 1 (db2inst1, 0)
Aug  5 10:31:39 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh
                                  [598080]: Returning 2 : db2inst1 db2inst1 HADRDB
Aug  5 10:31:44 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh 
                                  [471192]: Returning 3 : db2inst1 db2inst1 HADRDB
清单 20. 关于 HADR 启动脚本调用附近的备用 db2diag.log
2010-08-05-10.31.36.489581-240 I728601A485        LEVEL: Error
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47004
RETCODE : ZRC=0x8280001D=-2105540579=HDR_ZRC_NOT_TAKEOVER_CANDIDATE_FORCED
          "Forced takeover rejected as standby is in the wrong state or peer window 
           has expired"

2010-08-05-10.31.36.489773-240 I729087A363        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47008
MESSAGE : Info: Standby has failed to takeover.

试着增加 HADR_PEER_WINDOW 值。

集群管理器错误

在 db2diag.log 错误消息中,是否看到带有 “###---####-###” 标识符的错误?这表示此错误由 TSA/RSCT 直接返回,或者是 TSA/RSCT 在那个时刻无响应。参考 RSCT 信息中心,获取更多细节信息(见 参考资料 中的链接)。

故障转移失败

您可能已经了解,原有备用系统上假定主角色的主要步骤是 “db2 接管”。浏览 db2diag.log 看看是否有与此相关的消息。清单 21 展示了成功的接管消息的示例:

清单 21. 成功接管的消息
2010-08-06-10.31.20.530184-240 I8024A377          LEVEL: Warning
PID     : 622806               TID  : 4405        PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 4405                 EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47003
MESSAGE : Info: Standby has completed takeover (now primary).

看到了吗?

检查数据库当前 HADR 状态(通过 db2pd)。如果它不是主系统,试着手工输入 db2 接管命令。

清单 22. 输入 db2 接管命令
db2inst1@host2) /vbs/engn/ha/salinux $ db2 takeover hadr on db HADRDB
DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.

下一步

如果看完本节,问题还没解决,那最好打开 PMR。根据以上指导将所有发现描述清楚。此外,还应加入以下内容:

  • 手工运行的命令的输出结果
  • db2support
  • getsadata

重新集成故障

故障转移后,原始主系统恢复,并作为新的备用系统,这就是 “重新集成”。有些情况下,重新集成会失败,将集群域变成意料不到的状态。本节将探索可能导致集成失败的原因,并据此进一步调试。

需要问自己的问题:

  • HADR 在新的主系统上成功启动了吗?
  • 实例在原始主系统上成功启动了吗?

HADR 在新的主系统上成功启动了吗?

根据以上所述,原始主系统作为备用系统启动会有重新集成。这意味着 TSA/RSCT 调用了原始备用系统上的 HADR 启动脚本,从而导致发布了 “db2 takeover” 命令。如果接管不成功,就会导致 “未发生故障转移” 的情况。参考 “未发生故障转移” 一节,获得帮助。

实例在原始主系统上成功启动了吗?

重新集成的第一步是在原始主系统上启动实例,如果它还未启动的话。

  • 打开原始主系统上的系统日志。
  • 看到脚本调用了吗?
    • 是 - 继续调试。
    • 否 - 这很可疑。要看看系统日志中某一时间间隔调用的监控脚本。问问自己,“集群配置是否正确?是否启用了系统日志?”
  • 看到实例启动脚本调用了吗?(查找实例监控脚本 “Returning 2”。紧接着之后应该看到实例启动脚本调用。)
    • 是 - 继续调试。
    • 否 - 这与 TSA/RSCT 问题类似。联系 IBM Support。
  • 看到实例启动脚本成功返回了吗(有 “Returning 0”)?
    • 是 - 这意味着实例启动成功,并应该已重新集成。检查数据库配置参数或 db2pd 以确认 HADR 数据库角色。
    • 否 - 看看以下的可能根本原因。

db2gcf 超时

实例启动脚本使用 db2gcf 工具来启动实例。如果 db2gcf 超时,您将看到说明这一点的 db2diag.log 消息。

清单 23. db2diag.log 消息 - db2gcf 超时
2010-06-05-02.05.33.824563-240 I18731842A257      LEVEL: Error 
PID     : 1831554              TID : 1 
FUNCTION: DB2 Common, Generic Control Facility, GcfCaller::start, probe:40 
MESSAGE : ECF=0x9000028C Timeout occurred while calling a GCF interface function

试着手工启动实例,看看要多长时间(db2start)。还可以使用 db2gcf 启动实例,不指定超时时间,看看要多久:

db2gcf u i db2inst1

启动时间根据环境中的分区数不同而不同。但每个分区应在数秒之内。

db2start 故障

如果实例成功启动,在 db2diag.log 中就会有相关提示的信息。

清单 24. db2diag.log 消息 - 成功启动消息
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

试着手工启动实例,看看是否成功。

重新集成故障

本例中,实例启动成功,但原始主 HADR 数据库作为备用启动失败。如 “lsrsrc” 一节中所述,标志是用于 DB2 与 TSA/RSCT 通信的方法。在重新集成的情况中,新的主系统将创建一个重新集成标志。这是原始主系统作为备用启动的信号。一旦重新集成成功,标志就被删除。检查重新集成标志是否存在。如果仍然存在,这就明显说明重新集成故障与标志检测有关。

表 5 列举出与重新集成故障有关的 APARS。浏览一遍,看看是否适用于您目前的场景。

表 5. 重新集成 APARS
APARFixed in
IC65836 / IC65837V95FP6 / V97FP2
IC64142 / IC64666V95FP6 / V97FP2
IC67393V97FP2

下一步

如果看完本节,问题还没解决,那最好打开 PMR。根据以上指导将所有发现描述清楚。此外,还应加入以下内容:

  • 手工运行的命令的输出结果
  • db2support
  • getsadata

db2haicu 的配置问题

db2haicu 可用来集群化 HADR 设置。该工具在底层与 TSA/RSCT 交互,创建管理各种 DB2 实体的资源。在交互模式运行时,将会提示用户一系列问题。大多数情况下,如果用户输入不正确/不合适的答案,将会有相关提示。

本节将指导您如何识别错误输入不会被立即纠正(db2haicu 某些版本),从而导致集群运行不正常的情况。

db2haicu 安装过程中会出现两种故障:

要区分是无效输入还是 TSA/RSCT 错误,需要查看 db2diag.log。仔细查看日志中 “sqlha” 系列的函数。在数据字段中是否看到 ####-### 标识符?如果是,就说明集群管理器有错误。否则,可能是配置错误。数据部分应该指示它正试图采取动作的资源(例如,正试图创建或查找的资源或资源组名称)。

注意:DB2 HADR 的配置参数要求与 db2haicu 工具不同。由于这些不同之处,如果 HADR 数据库对运行正常,db2haicu 工具在创建集群域中资源时仍会失败。请参考 表 2 中细节信息。

常见的无效输入

大多数情况下 db2haicu 交互接口会拒绝明显的无效用户输入(例如,使用 VIP 身份的主机名)。尽管如此,有些配置错误却不会立即被发现,因此安装过程会在结束时失败,并发出一般消息。此时需要检查 db2diag.log 进一步调试。

让我们看看经常会产生无效输入的地方:

主机名

集成 HA 解决方案依赖来自各个主机的资源。因此,需要确认所有用户输入和系统设置一致。

要了解 TSA/RSCT 如何查看主机名,输入 lsrpnode 命令。

要了解 DB2 如何查看主机名,输入 uname。(注意事项: 好的做法是让 uname 主机名与主机名的输出保持一致。)

清单 25 显示了一些用户会请求主机名的地方。

清单 25. 主机名请求
Create a unique name for the new domain:
ha
Nodes must now be added to the new domain.
How many cluster nodes will the domain ha contain?
2
Enter the host name of a machine to add to the domain:
host1
Enter the host name of a machine to add to the domain:
host2
db2haicu can now create a new domain containing the 2 machines that you specified. 
If you choose not to create a domain now, db2haicu will exit.

Create the domain now? [1]
1. Yes
2. No
1
Creating domain ha in the cluster...
Creating domain ha in the cluster was successful.

对于 HADR 数据库,主机名在 HADR_LOCAL_HOSTHADR_REMOTE_HOST 参数中设定。如果此处设定的是 IP 地址,db2haicu 交互工具将会提示实际主机名。

清单 26. 提示主机名
Setting a high availability configuration parameter for instance db2inst1 to TSA.
Adding DB2 database partition 0 to the cluster...
Adding DB2 database partition 0 to the cluster was successful.
Do you want to validate and automate HADR failover for the HADR database HADRDB? [1]
1. Yes
2. No
1
Adding HADR database HADRDB to the domain...
The cluster node 9.26.53.5 was not found in the domain. Please re-enter the host name.
host1
The cluster node 9.26.53.50 was not found in the domain. Please re-enter the host name.
host2
Adding HADR database HADRDB to the domain...
The HADR database HADRDB has been determined to be valid for high availability. 
However, the database cannot be added to the cluster from this node because db2haicu 
detected this node is the standby for the HADR database HADRDB. 
Run db2haicu on the primary for the HADR database HADRDB to configure the database for 
automated failover.
All cluster configurations have been completed successfully. db2haicu exiting...

HADR_LOCAL_HOSTHADR_REMOTE_HOST 设定的参数将用作生成集群资源名称。如果主机名称源的格式不一致,将会导致故障。不一致将会导致 db2haicu 配置故障。最佳实践是在每个地方都是用规范主机名。

清单 27 和 28 显示了主机名不一致的情况下会出现的错误消息。

清单 27. db2haicu 中的错误消息
The HADR database HADRDB cannot be added to the cluster because the standby instance 
is not configured in the domain. Run db2haicu on the standby instance to configure it 
into the cluster.
All cluster configurations have been completed successfully. db2haicu exiting ...
清单 28. db2diag.log 中的错误消息
2010-08-04-13.45.17.792165+720 E258375A757        LEVEL: Error
PID     : 23901                TID  : 2199089142032PROC : db2haicu
INSTANCE: db2inst3             NODE : 000
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaAddResourceGroup, 
          probe:300
MESSAGE : ECF=0x90000557=-1879046825=ECF_SQLHA_CLUSTER_ERROR
          Error reported from Cluster
DATA #1 : String, 35 bytes
Error during vendor call invocation
DATA #2 : unsigned integer, 4 bytes
46
DATA #3 : String, 45 bytes
db2_db2inst3_lildb202.nz.thenational.com_0-rg
DATA #4 : unsigned integer, 4 bytes
1
DATA #5 : unsigned integer, 8 bytes
1
DATA #6 : signed integer, 4 bytes
0
DATA #7 : String, 0 bytes
Object not dumped: Address: 0x00000000800D59FC Size: 0 Reason: Zero-length data

HADR_REMOTE_INST

HADR 配置错误原因还有 HADR_REMOTE_INST,它区分 db2haicu 的大小写。

清单 29. db2diag.log 中的错误消息
2010-08-05-09.16.57.317614-240 E49090A665         LEVEL: Error
PID     : 717032               TID  : 1           PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaUICreateHADR, probe:895
RETCODE : ECF=0x9000056F=-1879046801=ECF_SQLHA_HADR_VALIDATION_FAILED
          The HADR DB failed validation before being added to the cluster
MESSAGE : Please verify that HADR_REMOTE_INST and HADR_REMOTE_HOST are correct
          and in the exact format and case as the Standby instance name and
          host name.
DATA #1 : String, 7 bytes
Db2inst1
DATA #2 : String, 10 bytes
host2

2010-08-05-09.16.57.317983-240 E49756A594         LEVEL: Error
PID     : 717032                TID  : 1          PROC : db2haicu
INSTANCE: db2inst1              NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaUICreateHADR, probe:900
RETCODE : ECF=0x9000056F=-1879046801=ECF_SQLHA_HADR_VALIDATION_FAILED
          The HADR DB failed validation before being added to the cluster
DATA #1 : String, 7 bytes
db2inst1
DATA #2 : String, 7 bytes
Db2inst1
DATA #3 : String, 10 bytes
host1
DATA #4 : String, 10 bytes
host2
DATA #5 : String, 7 bytes
HADRDB

通用命名格式

实例名不能包含下划线(_),因为它要用作 TSA/RSCT 资源的分隔符。它会导致解析不正确。V95FP6 (IC62705) 和 V97FP2 (IC64856) 已做了改进,允许实例名包含下划线。尽管如此,建议还是不要这样命名。

TSA/RSCT 命令故障

即使所有输入有效,db2haicu 配置仍有可能出现故障。配置过程中,db2haicu 将会调用 TSA/RSCT 来创建和注册各种资源。如果提供的调用返回错误,将会导致 db2haicu 退出失败。可以检查 db2diag.log 中包含 “### --- ####-###” 标识符的错误消息进行确认。清单 30 - 34 显示的是 db2haicu 和 db2diag.log 中表示常见故障的错误消息。

常见故障 #1

清单 30. db2haicu 中的典型错误消息
Create the domain now? [1]
1. Yes
2. No
1
Creating domain HA in the cluster ...
Creating domain failed. Refer to db2diag.log and the DB2 Information Center for details.
清单 31. db2haicu 中的典型错误消息
Adding DB2 database partition 0 to the cluster ...
There was an error with one of the issued cluster manager commands. Refer to db2diag.log 
and the DB2 Information Center for details.
清单 32. db2diag.log 中的典型错误消息
2010-01-06-14.31.50.656997-420 E3426E903           LEVEL: Error
PID     : 3485                 TID  : 48008924417584PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaCreateCluster, probe:900
MESSAGE : ECF=0x90000544=-1879046844=ECF_SQLHA_CREATE_CLUSTER_FAILED
          Create cluster failed
DATA #1 : String, 24 bytes
Error creating HA Domain
DATA #2 : String, 6 bytes
UC4GHA
DATA #3 : unsigned integer, 4 bytes
2
DATA #4 : signed integer, 4 bytes
21
DATA #5 : String, 350 bytes
Line # : 8839---2632-044 The domain cannot be created due to the following errors that 
         were detected while harvesting information from the target nodes:
         db200: 2610-441 Permission is denied to access the resource class specified 
         in this command. Network Identity UNAUTHENT requires 's' permission for the 
         resource class IBM.PeerDomain on node db200.

解决方案:preprpnode 不会在每个节点上运行。作为根用户,在每个节点上输入 TSA/RSCT 命令 preprpnode <host1> <host2>

常见故障 #2

清单 33. db2diag.log 中的典型错误消息
   2010-07-20-14.52.28.537943-240 E15731289A765      LEVEL: Error  
   PID     : 974914               TID  : 1           PROC : db2haicu  
   INSTANCE: db2inst1             NODE : 000  
   EDUID   : 1  
   FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure,  
   sqlhaAddResource, probe:1600  
   MESSAGE : ECF=0x90000542=-1879046846=ECF_SQLHA_CREATE_GROUP_FAILED  
             Create group failed  
   DATA #1 : String, 35 bytes  
   Error during vendor call invocation  
   DATA #2 : unsigned integer, 4 bytes  
   0  
   DATA #3 : String, 0 bytes  
   Object not dumped: Address: 0x0000000110165890 Size: 0 Reason: Zero-  
   length data  
   DATA #4 : unsigned integer, 8 bytes  
   1  
   DATA #5 : signed integer, 4 bytes  
   309  
   DATA #6 : String, 86 bytes  
   Line # : 7227---2621-309 Command not allowed as daemon does not have a  
   valid license.

解决方案:这是 TSA/RSCT 许可问题。从 Passport Advantage 获得许可,并用 samlic 命令来应用该许可。

常见故障 #3

清单 34. db2diag.log 中的典型错误消息
2010-07-20-14.52.28.538365-240 E15732055A369      LEVEL: Error  
PID     : 974914               TID  : 1           PROC : db2haicu  
INSTANCE: db2inst1             NODE : 000  
EDUID   : 1  
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure,  
sqlhaCreateNetwork, probe:50  
RETCODE : ECF=0x90000542=- RETCODE : 
          ECF=0x90000542=-1879046846=ECF_SQLHA_CREATE_GROUP_FAILED 
          Create group failed. 
Line # : 6531---host1: 2661-011 The command specified for attribute MonitorCommand is 
         NULL, not a absolute path, does not exist or has insufficient permissions to
         be run.

解决方案:这表示 sapolicies 脚本不在 /usr/sbin/rsct/sapolicies/db2 中。查看技术说明 “Error 'The command specified for attribute MonitorCommand is NULL' reported by db2haicu”(IBM,2010 年 3 月),其中有解决方法。(见 参考资料 中链接。)

关于其他集群管理器错误,请参考 RSCT 信息中心(见 参考资料 中链接)或联系 IBM Support。


结束语

读完本篇教程之后,您应该已更加深入地了解了 HA 架构各部分连接有何差异,以及如何使用工具对每个部件出现的问题进行调试。这些信息不仅在初始诊断时有用,同时也详细说明了 HA 架构各组件,讲解了这些组件如何协同工作,以及从 DB2 和 TSA/RSCT 角度看,每条诊断信息的含义。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, Tivoli
ArticleID=606711
ArticleTitle=通过 Tivoli Systems Automation 和 Reliable Scalable Cluster Technology 使用 DB2 High Availability Disaster Recovery
publish-date=01062011