解决 DB2 pureScale 集群服务环境中的问题

一种诊断信息收集与问题确认的系统性方法

本教程用于引导 DBA 与系统管理员确认 DB2 pureScale 集群服务方面的问题。当您将 IBM® DB2® pureScale® Feature for DB2 Enterprise Server Edition 系统部署到生产环境中时,您需要掌握正确的问题确认技巧。本教程提供了关于故障发生时收集诊断信息的相关信息,并提供额外信息以帮助您了解紧密集成的 DB2 pureScale Feature 子部件,如 Cluster Caching Facility (CF)、通用并行文件系统 (GPFS)、可靠的可伸缩集群技术 (RSCT) 与 IBM Tivoli Systems Automation for Multiplatforms (Tivoli SA MP)。

Oleg Tyschenko, DB2 pureScale 开发小组组长, IBM China

Oleg Tyschenko 的照片Oleg Tyschenko 是爱尔兰 DB2 引擎开发小组的负责人,也是 DB2 High Availability DB2 pureScale 开发小组的成员之一。他拥有 15 年以上关于信息管理及相关技术方面的经验。目前参与了欧洲许多DB2 pureScale 部署与概念验证项目。他所擅长领域包括 DB2 pureScale Feature、DB2 高可用性与集群管理、Tivoli SA for Multiplatforms,以及 GPFS 部署。Oleg 拥有华威商学院(英国)的计算机科学学位和 MBA 学位。



Massimiliano Gallo, DB2 功能测试工程师, IBM China

Massimiliano Gallo 的照片Massimiliano Gallo 是都柏林 DB2 Functional Verification Test 小组的资深成员之一,近几年一直致力于 DB2 pureScale 测试工作。他在软件开发与产品测试方面拥有 10 年以上的经验,精通大量技术。他所擅长的领域包括 DB2 pureScale Feature、DB2 高可用性与集群管理,以及 Tivoli SA for Multiplatform。Massimiliano 拥有罗马第一大学的航空与航天工程理科硕士学位。



2011 年 11 月 07 日

基础知识

免费下载:IBM® DB2® Express-C 9.7.2 免费版 或者 DB2® 9.7 for Linux®, UNIX®, and Windows® 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

IBM DB2 pureScale Feature for Enterprise Server Edition 提供了一种集群技术,该技术有助于交付具有高可用性与出色可伸缩性的应用程序,并为分布式平台带来最佳的架构。DB2 pureScale Feature 充许数据库经过计划外停机继续执行处理,并且可为任何事务工作负载提供几乎无限的容量。如果需要扩展系统,只需要连接到一台主机并发出两个简单的命令。DB2 pureScale Feature 所支持的基于集群的共享磁盘还可以帮助您通过高效地利用系统资源来降低成本。

DB2 pureScale Feature 结合了几种紧密集成的软件组件,在您部署 DB2 pureScale Feature 时,会自动安装和配置这些部件。您可以通过 DB2 管理视图和命令同 DB2 集群管理器和 DB2 集群服务方面的组件进行交互,如 db2instancedb2icrtdb2iupdtdb2cluster 工具。db2cluster 工具还提供故障排除与问题确认的选项。另外,DB2 集群管理器的子系统所生成的消息是问题确认方面非常好的信息来源。例如,DB2 集群服务所使用的资源类中的资源管理器均会将状态信息写入到它们的日志文件中。db2diag 日志文件还提供一些有用的信息。通常,db2diag 日志文件中的消息能说明发生故障的原因,并就如何解决问题给出了相关建议。

DB2 集群服务能够自动处理绝大多数运行时故障。然而,有些特定类型的故障需要您采取措施才能解决。例如,电源线可能被拔出或者网络电缆断开。如果 DB2 集群服务无法自动解决故障,就会发送警告给 DBA,通知有问题出现而且需要关注。DBA 在检查 DB2 实例的状态时便可看到这些警告,后面将会提到这一点。

了解 DB2 pureScale Feature 资源模型

9.8 版本的 DB2 pureScale Feature 资源模型与 9.7 版本单分区与多分区数据库环境中 HA DB2 实例所使用的资源模型不同。关于 DB2 pureScale Feature V 9.8 之前版本的 HA DB2 实例的更多信息,请参见本教程结尾 参考资料部分 中的背景信息链接。

DB2 pureScale Feature V 9.8 中所实现的新资源模型在表示集群缓存设备 (CF) 与共享集群化文件系统时是必不可少的。

在一个 DB2 pureScale 共享数据实例中,一个 CF 担任首要角色,其中包含该共享数据实例当前活动的数据。第二个 CF 保留了一份关于首要角色即时恢复的相关信息。

新的资源模型允许 IBM Tivoli® System Automation for Multiplatforms (Tivoli SA MP) 在首要 CF 节点出现故障时,正确地自动化 首要角色 的活动。

DB2 集群服务包含三个主要组件:

  • 集群管理器:Tivoli SA MP,其中包含了可靠的可伸缩集群技术 (RSCT)
  • 共享的集群化文件系统:IBM 通用并行文件系统 (GPFS)
  • DB2 集群管理:用于管理与监控集群的 DB2 命令与管理视图
图 1. DB2 集群服务
图表显示了连接到 DB2 数据服务器的客户端工作站,它拥有首要 CF、次要 CF、成员、DB2 集群服务与共享文件系统

DB2 集群服务为共享数据实例提供必要的基础设施,以便实现高可用性并在创建实例之后尽快提供自动的故障恢复与重新启动。

DB2 集群元素代表被监控而且状态变化由 DB2 集群服务管理的实体。就本文而言,我们将讨论三种 DB2 集群元素:

  • 主机:本机可以是物理计算机、物理计算机的逻辑分区 (LPAR) 或虚拟计算机。
  • DB2 成员:DB2 成员是核心处理引擎,通常位于其本地主机 上。DB2 成员的本地主机是在成员添加至 DB2 共享数据实例时以成员位置形式所提供的主机名。一个 DB2 成员拥有一台本地主机。只有当 DB2 成员在它们的本地主机上运行时,才能接受客户端连接。
  • 集群缓存设备 (CF):集群缓存设备 (CF) 是由 DB2 集群服务管理的软件应用程序,为 DB2 共享数据实例提供内部操作服务。

DB2 集群元素与底层的集群管理器资源以及资源组之间未必存在一对一的映射关系。

了解 DB2 pureScale Feature 如何自动处理故障

当 DB2 pureScale 实例中出现故障时,DB2 集群服务将自动尝试重新启动出现故障的资源。重新启动的时间与位置取决于各种因素,比如出现故障的资源类型和资源生命周期中出现故障的时间点。

如果主机上的软件或硬件故障导致 DB2 成员出现故障,DB2 集群服务将自动重新启动该成员。可以在两台任其一台相同主机上重启 DB2 成员(本地重启),如果启动失败,则在另一台主机上重启成员(在 restart light 模式下的重启成员)。在另一台主机上重启成员称为故障恢复

成员重启操作包括重启出现故障的 DB2 过程和执行成员崩溃恢复(撤消或重新应用日志事务),从而回滚所有 “动态的” 事务并释放它们持有的任何锁定。成员重启还能确保将更新后的页面写至 CF。

当在不同主机上以 restart light 模式重启成员时,新主机(是另一位 DB2 成员的本地主机)上使用的资源最少。以 restart light 模式运行的成员不会处理新事务,因为它的惟一目的就是执行成员崩溃恢复。故障成员上的数据库被尽可能快地恢复至一致的点。这使其他有效成员能够访问和修改由异常终止成员所锁定的数据库对象。所有来自故障成员的动态事务都被回滚,而所有在成员异常终止时持有的锁定都将被释放。尽管成员不接受新的事务,它仍然可以解决有疑问的事务。当一位 DB2 成员故障转移到新主机时,整个集群的总体处理能力暂时降低。当本地主机再次变为有效和可用状态时,DB2 成员将自动故障恢复到本地主机,而 DB2 成员也将在其本地主机上重启。当 DB2 成员故障恢复并在其本地主机上重启后,集群的处理能力就会立即恢复。所有其他 DB2 成员上的事务在故障恢复过程中均不会受到影响。


管理 DB2 pureScale Feature 的集群环境

DB2 集群服务提供了用于集群管理的 DB2 管理视图与命令。您可以使用 DB2 命令来管理共享文件系统与集群管理器,而无需使用单独的 Tivoli SA MP 或 GPFS 命令。例如,当您创建一个 DB2 实例和添加新的 DB2 成员或 CF 时,DB2 数据库管理器将自动针对 Tivoli SA MP 与 GPFS 调用正确的操作,从而根据需要建立或更新对等域。对等域是一个针对高可用性进行配置的主机集群,可以包含集群中的所有主机或者是总体集群解决方案中的一个主机子集。该对等域包含作为轮询策略中的故障恢复目标的主机,该主机是从可用主机列表中挑选出来的。

当 DB2 数据库管理器调用以下任意操作时,DB2 集群服务将监控与响应数据库集群命令:

  • 集群资源的创建与删除,作为安装与升级过程的一部分
  • 集群管理器与共享文件系统的扩展或收缩,以便纳入其他的主机或减少主机数量,作为添加或删除主机或 DB2 成员的一部分
  • 停止实例,以便进行无法在线执行的计划内维护

例如,您可以使用 db2cluster 命令进入维护模式,使用 db2icrt 命令创建一个新的 DB2 pureScale Feature 实例,并使用 db2iupdt 命令更新该实例。

使用 db2cluster 命令可以进一步管理 DB2 集群服务。

使用 db2cluster 命令诊断与修复问题

在某些罕见的情形下,集群资源模型可能会变得不一致,需要您进行手工干预。

db2clusterdb2instance 命令允许您收集关于资源模型状态的信息。

在本示例中,资源模型是健康的:

> db2cluster -cm -verify –resources
Cluster manager resource states for the DB2 instance are consistent.

在本示例中,资源模型是不一致的:

> db2cluster -cm -verify –resources
Cluster manager resource states for the DB2 instance are inconsistent. 
Refer to the db2diag.log for more information on inconsistencies.

当资源模型不一致时,您需要查看 db2diag 日志文件中的消息,以确认与问题相关的细节。通常,db2diag 日志文件中的消息会解释故障的原因,并就问题是内容以及如何解决问题给出了建议。例如,下面这条消息表明可能手动修改过 db2nodes.cfg 文件。如果情况属实,会建议您恢复至更早版本的 db2nodes.cfg 文件。如果情况不属实,会建议您使用 db2cluster 命令修复不一致的地方。

清单 1. 包含故障详细信息的 db2diag.log 文件
2011-05-25-15.01.21.776169+060 E13778E572            LEVEL: Info
PID     : 21058                TID  : 46912898085712 KTID : 21058
PROC    : db2cluster
INSTANCE: db2inst1                NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, sqlhaUISDVerifyResources, probe:0
MESSAGE : Resource verification failed.  Recommendation: if db2nodes.cfg was
          modified, return it to its original form.
DATA #1 : String, 124 bytes
Issue a 'db2cluster -cm -repair -resources' command to fix the inconsistencies 
if the db2nodes.cfg was not manually changed.

很多情况下,您可以使用 db2cluster 工具来修复资源,使用以下命令:

> db2cluster -cm -repair -resources
All cluster configurations have been completed successfully. db2cluster exiting...

注意,以上命令需要停止 DB2 实例。

在修复资源模型之后,集群管理器返回一种健康的操作状态,同时不会在任何实体上发出任何警告。要获得关于集群状态的进一步信息,您可以使用以下命令:

清单 2. db2instance -list 命令的输出
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME                   STATE                INSTANCE_STOPPED        ALERT
--------                   -----                ----------------        -----
hostD                      ACTIVE               NO                      NO
hostB                      ACTIVE               NO                      NO
hostC                      ACTIVE               NO                      NO
hostA                      ACTIVE               NO                      NO

以上 db2instance 示例的输出显示了一个健康的集群,它带有两个 DB2 成员与及两个 CF。集群中没有任何警告:所有 DB2 成员均在它们的本地主机上启动和操作。由 ID 128 代表的 CF 具有首要角色,而且所有主机都是有效的,每台主机上都启动了 DB2 实例。

我们可以使用以下命令再次核实是否没有任何警告:

> db2cluster -cm -list -alert
There are no alerts

您可以使用以下命令检查对等域中主机的状态:

清单 3. db2cluster -list -cm -host -state 命令的输出
> db2cluster -list -cm -host -state
HOSTNAME                    STATE
------------------------    -----------
hostA                       ONLINE
hostB                       ONLINE
hostC                       ONLINE
hostD                       ONLINE

这表示在所有主机上的对等域都处于在线和运行状态。

使用子系统消息与错误数据来排除 DB2 集群管理事件的故障

对于故障排除与问题确认,DB2 集群管理器的子系统所生成的消息是问题确认方面重要的信息来源。

在 Linux 平台上,这些消息被写入至系统日志中(/var/log/messages)。

在 AIX 平台上,系统日志记录默认没有配置,消息被写入到错误日志中。建议您在 /etc/syslog.conf 文件中配置系统日志记录。在更新 /etc/syslog.conf 之后,您必须运行 refresh –s syslogd 命令。

DB2 集群服务组件使用的资源类是由各种资源管理器 (RM) 来管理。哪个资源管理器负责管理哪类特定资源取决于资源类型。资源管理器以守护程序的形式运行,它是由系统资源控制器 (SRC) 进行控制。关于资源管理器的更多信息,请参考 Tivoli SA MP 管理员与用户指南。参考资料部分提供了相关的链接。

Global Resource RM (IBM.GblResRM)

Global Resource RM (IBM.GblResRM) 在每个节点上都维护一份审计日志,在其日记中记录了所有启动与停止命令及重置操作的执行情况。Global Resource RM 只在对等域 模式下是可以操作的。Global Resource RM 的日志位于:

/var/ct/<domain_name>/log/mc/IBM.GblResRM/

使用 db2cluster 命令可以找到域名:

> db2cluster -cm -list -domain
Domain Name: db2domain

要查看和审计日志,在节点上本地运行 rpttr 命令:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

注意,需要提供对 /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ 目录的根访问权限,从而像上面那样使用 rpttr 命令查看日志(关于允许权限较低的非根用户读取跟踪信息的其他方法,请参考 附录 A)。

下面的例子显示了审计日志中跟踪信息的格式:

清单 4. 已格式化的跟踪文件
[00] 04/15/11 17:07:43.324891 T(4150437552) ____  ******************* Trace Started - Pid 
= 7268 **********************
[00] 04/18/11 09:08:57.498711 T(4150433456) ____  ******************* Trace Started - Pid 
= 6735 **********************
[00] 04/19/11 11:41:31.832310 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:41:32.574276 T(4128861088) _GBD Monitor detect OpState change for resourc
e Name=instancehost_db2inst1_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b28
63 0x4a725d1a 0x1215ee4e 0xc2f1e0b0
[00] 04/19/11 11:42:07.255763 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518
[00] 04/19/11 11:42:08.973508 T(4123736992) _GBD Monitor detect OpState change for resourc
e Name=ca_db2inst1_0-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0x4a725d
1a 0x1215ee57 0xc96670b0
[00] 04/19/11 11:42:19.740162 T(4123638688) _GBD Monitor detect OpState change for resourc
e Name=primary_db2inst1_900-rs OldOpState=0 NewOpState=2 Handle=0x6028 0xffff 0xb82b2863 0
x4a725d1a 0x1215ee5a 0x63655418
[00] 04/19/11 11:50:14.697605 T(4123835296) _GBD Monitor detect OpState change for resourc
e Name=cacontrol_db2inst1_128_hostD OldOpState=2 NewOpState=1 Handle=0x6028 0xffff 0xb82b2
863 0x4a725d1a 0x1215ee57 0x8657b518

注意:为了轻松读取格式化的跟踪信息,您可以将 rpttr 命令输出重新定向至一个文件,因为该输出包含了大量的事件日志记录。

Recovery RM (IBM.RecoveryRM)

Recovery RM (IBM.RecoveryRM) 充当 Tivoli SA MP 的决策引擎。Recovery RM 运行在集群中的每个节点上,并将其中一个 Recovery RM 指定为主节点。主要的 Recovery RM 负责评估监控信息并根据 IBM.GlbResRM 提供的信息进行操作。当情况发展到需要干预时,Recovery RM 根据需要控制那些会导致对资源进行启动或停止操作的决策。

Recovery RM 的日志位于:

/var/ct/<domain_name>/log/mc/IBM.RecoveryRM/

主要的 Recovery RM 维护包含以下内容的审计日志:

  • 所有请求
  • 对请求的错误响应
  • 当前策略的相关信息
  • 绑定问题的相关信息

要查看日志,您需要在运行主要 Recovery RM 的主机上执行 rpttr 命令。首先,您可以使用 lssrc 命令来确定主机,例如:

清单 5. lssrc 命令的输出
lssrc -ls IBM.RecoveryRM | grep Master

Example output:
   Master Node Name     : hostD (node number =  4)
rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/trace_summary*

注意,需要提供对 /var/ct/<domain_name>/log/mc/IBM.RecoveryRM/ 目录的根访问权限,从而像上面那样使用 rpttr 命令查看日志(关于允许权限较低的非根用户读取跟踪信息的其他方法,请参考 附录 A)。

格式化跟踪文件示例如下:

清单 6. 已格式化的跟踪文件
[02] 05/25/11 14:59:25.487143 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.487651 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
1-rs/Fixed/IBM.Application/hostA  reported move state change: db2_db2inst1_1-rs/Fixed/IBM.
Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.488380 T(4112939936) _RCD Offline request injected: db2_db2inst1_0-
rg/ResGroup/IBM.ResourceGroup
[02] 05/25/11 14:59:25.488637 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Float/IBM.Application  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488914 T(4112939936) _RCD ReportMoveState: Resource : db2_db2inst1_
0-rs/Fixed/IBM.Application/hostA  reported move state change: a000 - preparing: 0
[02] 05/25/11 14:59:25.488955 T(4112939936) _RCD ReportState: Resource : db2_db2inst1_0-rs
/Fixed/IBM.Application/hostA  reported state change: 2
[02] 05/25/11 14:59:25.489642 T(4112939936) _RCD Offline request injected: idle_db2inst1_9
97_hostA-rg/ResGroup/IBM.ResourceGroup

注意:为了轻松读取格式化跟踪信息,您可以将 rpttr 命令输出重新定向至一个文件,因为该输出记录了大量的事件日志。

Configuration RM (IBM.ConfigRM)

Configuration RM (IBM.ConfigRM) 用在 DB2 pureScale Cluster Services 中。另外,它还提供 quorum 支持,可以在集群部分丢失通信时确保数据完整性。Configuration RM 只有在发生状态变化(有新事件出现)时才会更新其日志。该日志位于以下路径中:

/var/ct/IW/log/mc/IBM.ConfigRM/

集群拓扑服务用于注册 RSCT 对等域通信状态中的任何变化。如果网络适配器停止工作,该适配器的状态变化将被记录到 Configuration RM 跟踪中。拓扑服务日志位于以下路径中,其中 <domain_name> 为您的域名:

/var/ct/<domain_name>/log/cthats

“hatsd” 是首要的守护程序,它负责拓扑服务中大多数工作。它可执行更高级别的组织,包括创建心跳环路。心跳环路是每个节点向其中一位邻居发送一条消息并预期收到回复的进程。“hatsd” 守护程序有时无法检测到 Network Interface Module (NIM) 的拓扑状态变化,因此您应该首先检查 NIM 日志。主日志是以 "nim" 开始的,并包含正在受监控接口的名称:

nim.cthats.ib0 nim.cthats.ib0.001 nim.cthats.ib0.002 nim.cthats.ib0.003

NIM 使用的 netmon 库会监控每个适配器(由 NIM Topology Services 进程使用)的状态,以确定本地适配器是否还在工作。日志文件名等于 NIM 日志名称加上前缀 "nmDiag":

nmDiag.nim.cthats.ib0.001

GPFS 的日志文件

GPFS 同时将操作消息与错误数据写入到 MMFS 日志文件中。MMFS 日志文件位于每个节点的 /var/adm/ras 目录中,命名为 mmfs.log.date.nodeName,其中 date 是指 GPFS 实例在节点上启动时的时间戳,而 nodeName 是指节点的名称。您可以使用符号文件名 /var/adm/ras/mmfs.log.latest 查找最新的 MMFS 日志文件。

使用操作系统提供的错误日志记录工具的 GPFS 记录文件系统或磁盘故障:

  • Linux 平台上的 syslog 工具
  • AIX 平台上的 errpt 工具

您可以通过在 AIX 平台上执行以下命令来查看这些故障:

errpt -a

在 Linux 平台上执行此命令:

grep "mmfs:" /var/log/messages

场景 1:成员故障与其本地主机上的重启,带有附注释的日志

此场景包含 DB2 成员上出现软件故障与 DB2 成员可以在其本地主机上自动重启的情形。为了演示这个场景,将删除 DB2 成员上的 db2sysc 进程。

说明步骤之后,将详细解释在日志中写入了哪些信息。

首先,有四台主机(分别叫做 hostA、hostB、hostC 和 hostD),可以通过集群文件系统访问名为 db2inst1 的 DB2 实例中的共享数据。本实例包含两位成员:DB2 成员 0 运行在本地主机 hostA 上,而 DB2 成员 1 运行在本地主机 hostB 上。

db2instance 命令显示了健康集群的初始状态:

清单 7. 对健康集群使用 db2instance 命令的输出
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

为了演示 hostB 上 DB2 成员 1 出现软件故障时的行为,我们首先执行 psdb2 命令列出了 hostB 上当前实例 db2inst1 的所有数据库管理器进程:

清单 8. psdb2 的输出
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
25416 db2sysc 1
	
25440 db2vend (PD Vendor Process - 1) 0 0
	
25517 db2acd 1 ,0,0,0,1,0,0,0000,1,0,8a8e50,14,1e014,2,0,1,11fc0,0x210000000,0x210000000,1
600000,1138029,2,372802f

接着,我们使用 kill -9 25416 系统命令来删除与 hostB 上 DB2 成员相关的 db2sysc 进程:

> kill -9 25416

进程删除后,您就会看到 DB2 成员重启被初始化,我们可以在删除进程之后立即运行 db2instance 命令来查看这一点:

清单 9. 在删除进程后运行 db2instance 命令
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER RESTARTING hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

通过运行 psdb2 命令,我们还可以看到正在重启 DB2 成员的 db2start 进程:

清单 10. psdb2 输出显示 DB2 成员的重启
> psdb2
25014 db2sysc (idle 997)
25018 db2sysc (idle 998)
25027 db2sysc (idle 999)
	
27497 db2start NOMSG DATA 1 RESTART HOSTNAME hostB CM NETNAME hostB-ib0

您还可以从 lssam 命令输出中的资源模型获得资源状态:

清单 11. lssam 命令输出
Pending online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Pending online IBM.Application:db2_db2inst1_1-rs
|- Offline IBM.Application:db2_db2inst1_1-rs:hostA
'- Pending online IBM.Application:db2_db2inst1_1-rs:hostB

与 DB2 成员 1 相关的 db2_db2inst1_1-rs 资源处于 PENDING ONLINE 状态,这表示 DB2 集群服务正在重启该成员,正如 db2instance 命令所报告的一样。

当 DB2 成员在其本地主机上重启时,db2instance 命令会报告集群的状态已经恢复,而已重启的 DB2 成员也可以再次处理工作负载:

清单 12. db2instance 命令的输出
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostB     hostB        NO    0                0            hostB-ib0
128 CF     PRIMARY    hostC     hostC        NO    -                0            hostC-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

日志中相应的事件

当 hostB (IBM.RecoveryRM) 停止工作,会报告与 DB2 成员 1 相应的 db2_db2inst1_1-rs 资源:

2011-05-25 18:10:34.421792 R(hostA) T(4118616992) _RCD ReportState: Resource: db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 2

其后,Recovery RM 对其本地主机 hostB 上的 DB2 成员 1 上发出一个清除请求:

2011-05-25 18:10:34.583168 R(hostA) T(4118616992) _RCD Cleanup: Resource db2_db2inst1_1-rs
cleaned up on node hostB

报告该清除请求已经成功完成 (IBM.RecoveryRM):

2011-05-25 18:10:36.506559 R(hostA) T(4118616992) _RCD RIBME-HIST: db2_db2inst1_1-rs/Float
/IBM.Application Cleanup: Cleanup order successfully completed.

您还可以在 GblRes RM 日志中看到已执行的相应清除命令(IBM.GblResRM):

清单 13. 带清除命令的格式化跟踪文件
2011-05-25 18:10:34.584000 G(hostB) T(4125461408) _GBD Running cleanup command "/home/db2i
nst1/sqllib/adm/db2rocm 1 DB2 db2inst1 1 CLEANUP" for resource 0x6028 0xffff 0x5b83a378 0x
a4e2ad4a 0x1221057d 0xf2eda550. Supporter: 0x0000 0x0000 0x00000000 0x00000000 0x00000000 
0x00000000.
	
2011-05-25 18:10:36.498548 G(hostB) T(4122803104) _GBD Cleanup command for application 
resource "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 
0xf2eda550) succeeded with exit code 0

当 DB2 成员在其本地主机 hostB 上成功执行清除时,您可以在 db2diag 日志文件中看到相应的事件:

清单 14. 当 DB2 成员执行完清除操作时的 db2diag 日志文件
2011-05-25-18.10.36.485126-240 I128222E517           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-05-25-18.10.34.787912000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.36.492805-240 I132248E520           LEVEL: Event
PID     : 27434                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), 
PD_TYPE_SQLHA_ER_PDINFO, 80 bytes
Original timestamp: 2011-05-25-18.10.36.484918000
DATA #2 : String, 32 bytes
db2rocm 1 DB2 db2inst1 1 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

当清除完成之后,将发出一个在线请求,用于重启本地主机 hostB 上的 DB2 成员(IBM.RecoveryRM):

2011-05-25 18:10:36.563398 R(hostB) T(4118616992) _RCD Resource::doRIBMAction 
针对节点 hostB 上的 db2_db2inst1_1-rs 的在线请求.

最后,DB2 成员重启操作成功,相对应的资源状态再次报告为 ONLINE (IBM.RecoveryRM):

2011-05-25 18:10:54.947427 R(hostB) T(4118616992) _RCD ReportState: Resource : db2_db2inst
1_1-rs/Fixed/IBM.Application/hostB  reported state change: 1

您也可以看到相应的在线请求执行 (IBM.GblResRM):

清单 15. 相应在线请求执行
2011-05-25 18:10:36.563972 G(hostB) T(4128926624) _GBD Bringing application resource 
online: Name=db2_db2inst1_1-rs Handle=0x6028 0xffff 0x5b83a378 0xa4e2ad4a 
0x1221057d 0xf2eda550

2011-05-25 18:10:54.937889 G(hostB) T(4122803104) _GBD Start command for application resou
rce "db2_db2inst1_1-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x1221057d 0xf2eda550)
succeeded with exit code 0

查看 lssam 命令的输出,您将看到资源在其本地主机 hostB 上确实再次处于在线状态(而在可能的访客主机 hostA 上则是处于离线状态的):

清单 16. lssam 输出显示了本地主机上的资源在线
Online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
'- Online IBM.Application:db2_db2inst1_1-rs
'- Online IBM.Application:db2_db2inst1_1-rs:hostB

在 db2diag 日志文件中,记录了以下 DB2 成员启动事件:

清单 17. db2diag 日志文件显示 DB2 成员启动事件
2011-05-25-18.10.36.777580-240 I132769E364           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:949
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-05-25-18.10.54.932894-240 I534141E367           LEVEL: Event
PID     : 27496                TID  : 46912763496800 PROC : db2rocm 1 [db2inst1]
INSTANCE: db2inst1             NODE : 001
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1796
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 1 START
DATA #2 : String, 7 bytes
SUCCESS

DB2 成员 1 成功地在其本地主机 hostB 上完成重启,现在可以处理新事务。DB2 成员 1 的状态再次变为 STARTED,而且如果你使用 db2instance -list 命令查询成员状态,当前的主机仍然显示为 hostB。


场景 2:成员故障转移与故障恢复(电缆拔出场景),带有注释的日志

在这种场景中,出现了一个硬件错误。具体来说是有人不小心拔掉了 InfiniBand 通信电缆

DB2 集群服务在集群中另一台活动主机上以 restart light 模式自动重启成员。当出现故障的本地主机恢复在线时,处于 restart light 模式下的成员将自动故障恢复至它的本地主机,进而成为一个处于完全激活状态并可再次处理事务的成员。

说明步骤之后,将详细解释在日志中写入了哪些信息。

首先,有四台主机(分别叫做 hostA、hostB、hostC、hostD)可以通过集群化文件系统访问 DB2 实例(叫做 db2inst1)的共享数据。该实例包含两位成员:DB2 成员 0 运行在本地主机 hostA 上,而 DB2 成员 1 运行在本地主机 hostC 上。在各位成员与 CF 之间存在一个 InfiniBand 链接,这对于 DB2 成员与 CF 都很重要。

清单 18. db2instance 输出显示以下配置
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE                             NO           NO
hostB                ACTIVE                             NO           NO
hostC                ACTIVE                             NO           NO
hostD                ACTIVE                             NO           NO

当有人绊到而断开 InfiniBand 通信电缆时,DB2 集群服务检测到 hostA 上出现一个故障。hostA 上的网络接口资源状态变为 OFFLINE。您可以从 lssam 命令输出获得资源状态:

清单 19. 来自 lssam 命令的资源状态
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Offline IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

DB2 集群服务自动在访客主机上重启成员 0 :

清单 20. db2instance 显示成员 0 的重启
>$ db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER RESTARTING hostA   hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For 
more information on the alert, its impact, and how to clear it, run the following 
command: 'db2cluster -cm -list -alert'.

当 DB2 集群服务完成成员 0 的重启时,我们可以看到它已经在访客主机 hostC 上重启:

清单 21. db2instance 显示警告
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER WAITING_FOR.hostA  hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1

HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      YES
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
There is currently an alert for a member, CF, or host in the data-sharing instance. For 
more information on the alert, its impact, and how to clear it, run the following 
command: 'db2cluster -cm -list -alert'.


$ db2cluster -cm -list -alert
1.
Alert: Host 'hostA' is not responding on the network adapter 'ib0'. Check the operating
system for error messages related to this network adapter and chec k the connections to 
the adapter as well.

Action: This alert will clear itself when the network adapter starts to respond. This 
alert cannot be cleared manually with db2cluster.

Impact: DB2 members and CFs on the affected host that require access to network adapter 
'ib0' will not be operational until the problem is resolved. While the network adapter 
is offline, the DB2 members on this host will be in restart light mode on other systems, 
and will be in the WAITING_FOR_FAILBACK state. The affected CFs will not be available 
for CF failover and will remain in the STOPPED state until the network adapter issue is 
resolved.

在把 InfiniBand 电缆插回去之后,DB2 集群服务自动检测到 hostA 恢复在线,并将 hostA 的网络接口重置为 ONLINE:

清单 22. 网络接口重置
Online IBM.Equivalency:db2_private_network_db2inst1_0
|- Online IBM.NetworkInterface:ib0:hostA
'- Online IBM.NetworkInterface:ib0:hostC

接下来,DB2 集群服务终止访客主机 hostC 上的 DB2 成员 0,并调用本地主机 hostA 上 DB2 成员 0 的常规 DB2 重启:

清单 23. 本地主机上 DB2 成员 0 的重启
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0  MEMBER STARTED    hostA   hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib1
129 CF     CATCHUP    hostD     hostD        NO    -                0            hostD-ib1
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO
> db2cluster -cm -list -alert
There are no alerts

日志中相应的事件:

对应于主机 hostA 上的适配器 ib0 的网络接口被报告为处于停止工作状态 (IBM.RecoveryRM):

2011-02-28 06:15:26.411814 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 2

Recovery RM 发出一个离线请求到期本地主机 hostA 上的成员 0 上:

清单 24. 发给成员 0 的离线请求
2011-02-28 06:15:26.421832 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:15:26.425470 G(hostA) T(4127394720) _GBD Taking application resource offline
: Name=db2_db2inst1_0-rs Handle=0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740
2011-02-28 06:15:26.425613 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 6
2011-02-28 06:15:29.009743 G(hostA) T(4123753376) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740) 
succeeded with exit code 0
2011-02-28 06:15:29.288071 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 2

当成员已经在其本地主机 hostA 上成功停止后,您可以在 db2diag 日志文件中看到相应的事件:

清单 25. 成员已经在本地主机上停止时的 db2diag.log 文件
2011-02-28-06.15.28.988205-300 I981598E541           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.26.693115000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.29.001230-300 I984566E544           LEVEL: Event
PID : 1613                     TID : 46912880928864  KTID : 1613
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.15.28.987779000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

现在,成员 0 在访客主机 hostC 上被重启 (IBM.RecoveryRM):

清单 26. 在访客主机上重启的成员 0
2011-02-28 06:15:29.439708 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:15:35.491788 G(hostC) T(4122594208) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620)
succeeded with exit code 0
2011-02-28 06:15:35.496093 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostC reported state change: 1

db2diag 日志文件显示:

清单 27. 显示访客主机上的启动的 db2diag.log
2011-02-28-06.15.29.710141-300 I996097E381           LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.15.35.482268-300 I1342111E384          LEVEL: Event
PID : 17290                    TID : 46912880937056  KTID : 17290
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

当 InfiniBand 电缆被插回之后,hostA 上的适配器 (ib0) 再次报告为在线状态 (IBM.RecoveryRM):

2011-02-28 06:22:40.503749 R(hostA) T(4117486496) _RCD ReportState: Resource : ib0/Fixed/I
BM.NetworkInterface/hostA reported state change: 1

因此,成员 0 在访客主机 hostC 上被停止:

清单 28. 在访客主机上被停止的成员 0
2011-02-28 06:22:40.549388 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Offline Requ
est against db2_db2inst1_0-rs on node hostC.
2011-02-28 06:22:43.402484 G(hostC) T(4122594208) _GBD Stop command for application resour
ce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x5b83a378 0xa4e2ad4a 0x120693f5 0xeea67620) 
succeeded with exit code 0

db2diag 日志文件显示该事件:

清单 29. 显示事件的 db2diag 日志
2011-02-28-06.22.43.373821-300 I2291438E542          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.40.810556000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.43.392086-300 I2295670E545          LEVEL: Event
PID : 19699                    TID : 46912880937056  KTID : 19699
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostC
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-02-28-06.22.43.373504000
DATA #2 : String, 40 bytes
db2rocm 1 DB2 db2inst1 0 STOP (SA_RESET)
DATA #3 : String, 7 bytes
SUCCESS

现在,成员 0 在其本地主机 hostA 上被重启(IBM.RecoveryRM):

清单 30. 在本地主机上重启的成员 0
2011-02-28 06:22:43.825145 R(hostA) T(4117486496) _RCD Resource::doRIBMAction Online Reque
st against db2_db2inst1_0-rs on node hostA.
2011-02-28 06:22:55.189619 G(hostA) T(4123360160) _GBD Start command for application resou
rce "db2_db2inst1_0-rs" (handle 0x6028 0xffff 0x77babcfd 0xac578906 0x120693f5 0xeea64740)
succeeded with exit code 0
2011-02-28 06:22:55.193415 R(hostA) T(4117486496) _RCD ReportState: Resource : db2_db2inst
1_0-rs/Fixed/IBM.Application/hostA reported state change: 1

db2diag 日志文件显示该事件:

清单 31. 显示重启成员 0 的 db2diag 日志文件
2011-02-28-06.22.44.102847-300 I2369547E380          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:915
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-02-28-06.22.55.178487-300 I2763321E383          LEVEL: Event
PID : 4468                     TID : 46912880928864  KTID : 4468
PROC : db2rocm 0 [db2inst1]
INSTANCE: db2inst1             NODE : 000
HOSTNAME: hostA
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1590
DATA #1 : String, 30 bytes
db2rocm 1 DB2 db2inst1 0 START
DATA #2 : String, 7 bytes
SUCCESS

场景 3:Cluster Caching Facility (CF) 接管

在这种场景中,DB2 pureScale Feature 实例配置了两个集群缓存设备 (CF) 。一个被指定为首要 CF,而另一个为次要 CF。DB2 成员自动复制关键信息(如锁定修改状态和群组缓冲池页面)给这两个 CF。因为在场景一开始,次要 CF 处于对等状态,我们知道关键信息被复制到次要 CF 上并且是最新的。如果首要 CF 出现故障,次要 CF 快速接管首要 CF 的职责,这样几乎看不到应用程序的故障。

首先,有四台主机(分别叫做 hostA、hostB、hostC、hostD)可以通过集群化文件系统访问 DB2 实例(叫做 db2inst1)的共享数据。 DB2 成员 0 运行在本地主机 hostA 上,而 DB2 成员 1 则运行在本地主机 hostB 上。在各位成员与 CF 之间存在一个 InfiniBand 链接,这对于 DB2 成员与 CF 都很重要,因此成员与 CF 均具有等价的 InfiniBand 依赖性。

清单 32. db2instance 输出显示配置
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PRIMARY    hostB     hostB        NO    -                0            hostB-ib0
129 CF     PEER       hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

如果 CF 在 hostB 上出现故障,首要角色将被故障转移给处于对等状态的次要 CF。 DB2 集群服务将检测到 CF 进程在本地主机上被关闭,并调用出现故障的主机上的 CF 清除命令 (IBM.RecoveryRM):

清单 33. 集群服务检测到 CF 进程关闭并调用清除
2011-04-21 11:17:49.485951 G(hostB) T(4124957600) _GBD Monitor detect OpState change for r
esource Name=ca_db2inst1_0-rs OldOpState=1 NewOpState=2 Handle=0x6028 0xffff 0x88a0f77a 0x
4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:17:49.547613 R(hostB) T(4118584224) _RCD Cleanup: 
Resource ca_db2inst1_0-rs/Concurrent/IBM.Application cleanup order for constituent 
a_db2inst1_0-rs/Fixed/IBM.Application/hostB

db2diag 日志文件包含发出此命令与清除结果的日志记录:

清单 34. 显示清除的 db2diag 日志文件
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

首要角色在次要 CF (位于 hostD 上)上启动:

清单 35. db2instance 显示在次要 CF 上启动的首要角色
> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     RESTARTING hostB     hostB        NO    -                0            hostB-ib0
129 CF     BECOMING_PR.hostD   hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

IBM.RecoveryRM:

清单 36. IBM.RecoveryRM
2011-04-21 11:17:52.137049 G(hostB) T(4124760992) _GBD Stop command for application resour
ce "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f06 0xe30a
b210) succeeded with exit code 0
2011-04-21 11:17:52.537322 R(hostB) T(4118584224) _RCD Cleanup: Resource primary_db2inst1_
900-rs/Fixed/IBM.Application/hostD is dirty.
2011-04-21 11:17:52.539174 G(hostD) T(4128926624) _GBD Bringing application resource onlin
e: Name=primary_db2inst1_900-rs Handle=0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe3
85c1f8
2011-04-21 11:17:52.543773 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against primary_db2inst1_900-rs on node hostD.
2011-04-21 11:18:08.446049 G(hostD) T(4123556768) _GBD Start command for application res
ource "primary_db2inst1_900-rs" (handle 0x6028 0xffff 0x1802cd9b 0xb77f5380 0x12168f06 0xe
385c1f8) succeeded with exit code 0

db2diag 日志文件包含首要角色重启的以下事件:

清单 37. 显示首要角色重启的事件的 db2diag 日志文件
2011-04-21-11.17.52.784069-240 I45349553E400         LEVEL: Event
PID     : 2560                 TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1             NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMARY db2inst1 900 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.08.440950-240 I46272100E403         LEVEL: Event
PID     : 2560            TID  : 46912733618560 PROC : db2rocme 900 [db2inst1]
INSTANCE: db2inst1        NODE : 900
HOSTNAME: hostD
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 63 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 PRIMARY db2inst1 900 START
DATA #2 : String, 7 bytes
SUCCESS

DB2 集群服务尝试重启 hostB 上出现故障的 CF 进程。当成功重启 CF 之后,它会变为 CATCHUP 状态,而当故障转移完成后又变为 PEER 状态。

图 2. Cluster Caching Facility 状态迁移
图表显示连接至 DB2 数据服务器的客户端工作站, 它与集群缓冲设备相连接

Recovery RM 日志显示:

清单 38. IBM.RecoveryRM 日志
2011-04-21 11:17:53.885765 G(hostB) T(4124269472) _GBD Cleanup command for application res
ource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
) succeeded with exit code 0
2011-04-21 11:17:53.964794 R(hostB) T(4118584224) _RCD Resource::doRIBMAction Online Reque
st against ca_db2inst1_0-rs on node hostB.
2011-04-21 11:17:53.966743 G(hostB) T(4128926624) _GBD Bringing application resource onlin
e: Name=ca_db2inst1_0-rs Handle=0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f02 0x33bd39f8
2011-04-21 11:18:08.947076 G(hostB) T(4124269472) _GBD Start command for app
lication resource "ca_db2inst1_0-rs" (handle 0x6028 0xffff 0x88a0f77a 0x4444ff43 0x12168f0
2 0x33bd39f8) succeeded with exit code 0

db2diag 日志文件显示:

清单 39. db2diag.log 文件
2011-04-21-11.17.54.442397-240 I45376528E522         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.50.333529000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 5 bytes
BEGIN
	
2011-04-21-11.17.54.450788-240 I45379976E525         LEVEL: Event
PID     : 4287                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : SQLHA Event Recorder header data (struct sqlhaErPdInfo), PD_TYPE_SQLHA_ER_PDINFO
, 80 bytes
Original timestamp: 2011-04-21-11.17.54.442222000
DATA #2 : String, 34 bytes
db2rocme 1 CF db2inst1 128 CLEANUP
DATA #3 : String, 7 bytes
SUCCESS

2011-04-21-11.17.54.787350-240 I45392043E395         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:927
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 5 bytes
BEGIN
	
2011-04-21-11.18.09.512434-240 I46330550E398         LEVEL: Event
PID     : 4358                 TID  : 46912733618560 PROC : db2rocme 128 [db2inst1]
INSTANCE: db2inst1             NODE : 128
HOSTNAME: hostB
FUNCTION: DB2 UDB, high avail services, db2rocm_main, probe:1639
DATA #1 : String, 58 bytes
/home/db2inst1/sqllib/adm/db2rocme 1 CF db2inst1 128 START
DATA #2 : String, 7 bytes
SUCCESS

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     CATCHUP   hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

> db2instance -list
ID  TYPE   STATE      HOME_HOST CURRENT_HOST ALERT PARTITION_NUMBER LOGICAL_PORT NETNAME
--  ----   -----      --------- ------------ ----- ---------------- ------------ -------
0   MEMBER STARTED    hostA     hostA        NO    0                0            hostA-ib0
1   MEMBER STARTED    hostC     hostC        NO    0                0            hostC-ib0
128 CF     PEER      hostB    hostB        NO    -                0            hostB-ib0
129 CF     PRIMARY    hostD     hostD        NO    -                0            hostD-ib0
	
HOSTNAME             STATE                INSTANCE_STOPPED        ALERT
--------             -----                ----------------        -----
hostA                ACTIVE               NO                      NO
hostB                ACTIVE               NO                      NO
hostC                ACTIVE               NO                      NO
hostD                ACTIVE               NO                      NO

注意在这相似的场景中,如果次要 CF 并 不是 处于 PEER 状态,情况会更加复杂。在这种情况下,事务处理会被中断,故障会影响与数据库连接的客户端。当次要 CF 不是处于 PEER 状态时,它没有关于共享数据实例的状态的最新信息。因此,如果首要 CF 出现故障,共享数据实例必须执行一次群组重启。DB2 集群服务将自动启动群组重启。


结束语

有许多可以提供 DB2 pureScale 集群状态的重要信息来源。DB2 集群服务监控事件并撰写日志,该日志记录了关于成功与失败情形的相关信息。您可以通过使用 db2clusterdb2instance 命令和这些 DB2 集群服务日志信息,了解集群中发生的事情,以及诊断与修复问题。

如果您使用 IBM 技术支持,还可以使用 db2support 命令来收集 DB2 pureScale 集群服务的诊断数据、跟踪与日志文件,以及 DB2 日志信息。您可以将输出文件发送给 IBM 技术支持,以进行进一步的调查与诊断。


附录 A:读取资源管理器跟踪所需的访问权限

为了格式化和读取资源管理器跟踪,例如那些位于 /var/ct/< domain_name >/log/mc/IBM.GblResRM/ 中的跟踪,使用以下命令:

rpttr -o dtic /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary*

您应该拥有对 /var/ct/< domain_name >/log/mc/IBM.GblResRM/ 目录的读写权限,以及对该目录中包含的日志文件的读权限。

如果没有对该目录的写入权限,只要有对该目录与日志文件的读取权限也已足够了。这样,您就可以使用以下方法来读取日志:

清单 40. 在不支持写权限的情况下读取日志的方法
mkdir ~/gblresrm_logs_copy
cp /var/ct/<domain_name>/log/mc/IBM.GblResRM/trace_summary* ~/gblresrm_logs_copy

rpttr -o dtic ~/gblresrm_logs_copy/trace_summary*
rpttr -o dtic ~/gblresrm_logs_copy/trace_summary* > formatted_gblresrm.log

注意默认情况下,日志文件权限设定为根目录读写权限。因此,管理员必须为指定用户提供访问这些日志文件所必要的权限。


背景信息

以下可选信息仅供参考。

Tivoli SA MP 与以前版本的 DB2 数据库管理器

DB2 数据库管理器与 Tivoli SA MP 的集成已有一段时间。DB2 数据库系统 V 9.5 与 9.7 均集成了 Tivoli SA MP,以提供数据库分区功能、ESE 单一分区以及高可用性与灾难恢复 (HADR),但没有默认使用 Tivoli SA MP 或集群管理自动化。集群的初始创建与 DB2 分区的增加或删除均需要几个手动步骤。

参阅参考资料部分中相关书籍及更多资源的链接,获得关于 9.8 版本之前 DB2 数据库系统与 Tivoli SA MP 集成的详细信息。


参与者

除了作者之外,以下个人也对本教程作出了贡献:

  • Joyce Simmonds,DB2 信息开发人员
  • Nikolaj Richers,DB2 信息开发人员

参考资料

学习

讨论

条评论

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=772614
ArticleTitle=解决 DB2 pureScale 集群服务环境中的问题
publish-date=11072011