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

基础知识

简介

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

DB2 pureScale Feature 结合了几种紧密集成的软件组件，在您部署 DB2 pureScale Feature 时，会自动安装和配置这些部件。您可以通过 DB2 管理视图和命令同 DB2 集群管理器和 DB2 集群服务方面的组件进行交互，如 db2instance、db2icrt、db2iupdt 与 db2cluster 工具。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 命令与管理视图

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 成员上的事务在故障恢复过程中均不会受到影响。

1 页，共 11 | 后一页

评论

回页首

内容

• 基础知识
• 管理 DB2 pureScale Feature 的集群环境
• 场景 1：成员故障与其本地主机上的重启，带有附注释的日志
• 场景 2：成员故障转移与故障恢复（电缆拔出场景），带有注释的日志
• 场景 3：Cluster Caching Facility (CF) 接管
• 结束语
• 附录 A：读取资源管理器跟踪所需的访问权限
• 背景信息
• 参与者
• 参考资料
• 作者简介

---

1 页，共 11 | 后一页