内容发布更新时间 : 2024/5/22 3:02:27星期一 下面是文章的全部内容请认真阅读。
DB2 pureScale 的新特性介绍 -- Group Crash Recovery
武翠霞, 软件工程师, EMC 张玉颖, 软件工程师, IBM
简介： 本文主要介绍了 DB2 pureScale 的结构，以及新特性 Group Crash Recovery ，并通过 DB2 V9.8 的实例进行了详细说明。 引言
DB2 V9.8（pureScale）最重要特性就是其高度的伸缩性， 这是 DPF，HADR 所不能满足的。在 pureScale 中所有的数据都是在一个共享的地方存放，这点与 DB2 for z/OS 的存储结构类似。
在 pureScale 中引入了 member 的概念，相当与 DPF 的 partition。一组 member 的集合就是一个 Cluster（集群）。
在 pureScale 中还有 Cluster Facilitator，它来确保 cross member 数据的一致性，可以配置一个或者两个 CF。CF 的主要组件包括以下三部分。 Global Buffer Pool (GBP) ：保证集群上缓存中的共享数据页的一致性 ? Global Lock Manager (GLM) ：保证集群上共享数据更改的一致性 ? Shared Communications Area (SCA) ：对 DB2 控制数据（比如：控制块，日志序列数（LSN））提供一致机制。
?
Shared Data 结构介绍
Shared Data（SD） 是一种全新的数据存储方式。在这种方式中，所有的数据都是共享的，member1 可以读取 member2 的数据，但每个 member 只能在自己的日志路径上写日志。图 1 显示了 SD 结构。
图 1. SD 结构图
可见数据是共享的，每个 member 都使用相同的 log 参数，日志放在集群文件系统中，member 各自写各自的日志，但可以读其他 member 的日志。以三个 member 为例，其日志路径分别为：
yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0000, yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0001, yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0002
在 pureScale 中最多支持 128 个 member，以三个 member 和两个 CF 为例，数据库配置如清单 1 和清单 2 所示。
清单 1. 逻辑配置（member 和 CF 在一个物理机器上） cd /home/wucuixia/sqllib_shared cat db2nodes.cfg
0 coral253 0 - - MEMBER 1 coral253 1 - - MEMBER 2 coral253 2 - - MEMBER 128 coral253 0 - - CF 129 coral253 0 - - CF
清单 2. 物理配置（member 和 CF 在多个物理机器上） cd /home/wucuix2/sqllib_shared cat db2nodes.cfg
0 coralxib14 0 - - MEMBER 1 coralxib15 0 - - MEMBER 2 coralxib16 0 - - MEMBER 128 coralxib17 0 - - CF 129 coralxib16 0 - - CF
Group Crash Recovery 介绍
DB2 现有的恢复方式有 HADR，Version Recovery，Crash Recovery，Rollforward Recovery，现在 Group/Member Crash Recovery 是 pureScale 引入的新的 Crash Recovery。
在只有一个 CF 的情况下，如果 CF Down 掉了，就需要进行 Group Crash Recovery；如果 CF 正常工作，某一个或多个 member 不能工作，则需要进行 Member Crash Recovery。如果有一个主 CF 和一个辅助 CF，在两种情况下需要进行 Group Crash Recovery。一种是如果锁双工运行，当主 CF 和辅助 CF 同时不能工作，或者主 CF 不能工作同时辅助 CF 未达到 peer 状态时，需要 Group Crash Recovery；另一种情况是在锁非双工运行时，当主 CF 和辅助 CF 同时不能工作时需要 Group Crash Recovery。
本文主要介绍 Group Crash Recovery 新特性。在数据库中，Group Crash Recovery 可以在任何一个 member 上发生，并且只能在一个 member 上进行。如果不指定 member，默认是第一个 member，可以使用 export DB2NODE=2 来设定 member2, 然后连接数据库来触发 Group Crash Recovery。
在共享数据环境中，会有 Cluster Manager 的概念。它的一个职责是确保数据库是尽可能是一直可用的，这就包含了自动启动 Group Crash Recovery 的功能。因此只有 CM 出问题时，才需要手动执行 Group Crash Recovery。
如果要手动启动 Group Crash Recovery，如果 AUTORESTART 参数为 ON, 可以使用 CONNECT TO 或者 ACTIVATE DATABASE 命令， 如果 AUTORESTART 是 OFF, 则可以使用 RESTART DATABASE 命令。当 RESTART DATABASE, ACTIVATE DATABASE 或者 CONNECT TO 命令完成后，执行命令的 member 就可以接受新的请求，数据库也就可以使用了，但没有解决 in-doubt transaction 的数据页还是不能建立连接。
Group Crash Recovery 的特点
与以前版本的 Crash Recovery 相比，Group Crash Recovery 有以下几点不同： 可能从 log archive 中恢复文件
即使没有指定 infinite active logging，某些时候 Group Crash Recovery 仍然会从 log archive 中获取文件。比如当一个 member Down 掉了，并长时间没