DB2 pureScale集群HADR管理

关于pureScale集群HADR的特性介绍已经在上一篇文章《实战Db2 purescale集群HADR容灾解决方案上 - 安装配置篇》做了详细介绍。上篇内容也提供了详细的案例去安装和配置HADR功能，包括数据库的客户端驱动如何配置才能自动重路由。

当HADR功能工作后，下一步就是要知道HADR工作的好不好，也就是需要实时监控HADR的状态和性能。例如状态会分哪几种情况，何为正常，HADR的性能如何，有没有导致数据延迟，如果延迟，是发生在什么地方，等等。然后在这种复杂的环境下，维护类操作该怎么处理，需要遵循什么流程。本篇文章将详细阐述这些问题。

实战DB2 pureScale集群HADR监控

关于pureScale HADR环境的监控和普通的单机版监控类似，都可以通过db2pd工具来实现。但是由于集群环境的特殊性，需要监控的内容和单机版DB2有所区别。db2pd工具会返回当前节点的HADR信息。

监控DB2 pureScale集群HADR

因为DB2 pureScale是多节点的集群架构，所以在主集群建议结合使用db2_all命令和db2pd命令来返回所有节点的HADR状态信息，备集群在replay member上使用db2pd能获取所有节点HADR信息。

清单13.db2pd监控HADR

$db2pd -db TESTDB -hadr

Database Member 0 -- Database TESTDB -- Active -- Up 0 days 00:51:36 -- Date 2013-05-10-11.58.25.516351

                            HADR_ROLE = PRIMARY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = ASYNC
                           STANDBY_ID = 1
                        LOG_STREAM_ID = 0
                           HADR_STATE = DISCONNECTED
                           HADR_FLAGS = 
                  PRIMARY_MEMBER_HOST = purescaleam1
                     PRIMARY_INSTANCE = db2sdin1
                       PRIMARY_MEMBER = 0
                  STANDBY_MEMBER_HOST = purescalebm1
                     STANDBY_INSTANCE = db2sdin1
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = DISCONNECTED
             HADR_CONNECT_STATUS_TIME = 05/10/2013 11:55:50.069009 (1368158150)
          HEARTBEAT_INTERVAL(seconds) = 30
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 0
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.525169
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 99.801
                  LOG_HADR_WAIT_COUNT = 319081
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 131400
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 65700
            PRIMARY_LOG_FILE,PAGE,POS = S0003090.LOG, 1672, 314918576313
            STANDBY_LOG_FILE,PAGE,POS = S0003080.LOG, 23429, 313988260680
                  HADR_LOG_GAP(bytes) = 19357675
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0003080.LOG, 23418, 313988214157
       STANDBY_RECV_REPLAY_GAP(bytes) = 1223305934
                     PRIMARY_LOG_TIME = 05/10/2013 11:58:25.000000 (1368158305)
                     STANDBY_LOG_TIME = 05/10/2013 11:53:48.000000 (1368158028)
              STANDBY_REPLAY_LOG_TIME = 05/10/2013 11:53:48.000000 (1368158028)
         STANDBY_RECV_BUF_SIZE(pages) = 4302
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 3750000
                STANDBY_SPOOL_PERCENT = 0
                 PEER_WINDOW(seconds) = 0
             READS_ON_STANDBY_ENABLED = N
             
             
             


                            HADR_ROLE = STANDBY
                          REPLAY_TYPE = PHYSICAL
                        HADR_SYNCMODE = ASYNC
                           STANDBY_ID = 0
                        LOG_STREAM_ID = 1
                           HADR_STATE = REMOTE_CATCHUP_PENDING
                           HADR_FLAGS = 
                  PRIMARY_MEMBER_HOST = purescaleam2
                     PRIMARY_INSTANCE = db2sdin1
                       PRIMARY_MEMBER = 1
                  STANDBY_MEMBER_HOST = purescalebm1
                     STANDBY_INSTANCE = db2sdin1
                       STANDBY_MEMBER = 0
                  HADR_CONNECT_STATUS = DISCONNECTED
             HADR_CONNECT_STATUS_TIME = 05/10/2013 11:56:14.437190 (1368158174)
          HEARTBEAT_INTERVAL(seconds) = 30
                HADR_TIMEOUT(seconds) = 120
        TIME_SINCE_LAST_RECV(seconds) = 0
             PEER_WAIT_LIMIT(seconds) = 0
           LOG_HADR_WAIT_CUR(seconds) = 0.000
    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000011
   LOG_HADR_WAIT_ACCUMULATED(seconds) = 246.329
                  LOG_HADR_WAIT_COUNT = 39081
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 16384
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 16384
            PRIMARY_LOG_FILE,PAGE,POS = S0001315.LOG, 14491, 83413266682
            STANDBY_LOG_FILE,PAGE,POS = S0001315.LOG, 14491, 83413266682
                  HADR_LOG_GAP(bytes) = 8536
     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0001315.LOG, 14490, 83413265178
       STANDBY_RECV_REPLAY_GAP(bytes) = 129892
                     PRIMARY_LOG_TIME = 05/10/2013 11:54:13.000000 (1368158053)
                     STANDBY_LOG_TIME = 05/10/2013 11:54:13.000000 (1368158053)
              STANDBY_REPLAY_LOG_TIME = 05/10/2013 11:54:12.000000 (1368158052)
         STANDBY_RECV_BUF_SIZE(pages) = 4302
             STANDBY_RECV_BUF_PERCENT = 0
           STANDBY_SPOOL_LIMIT(pages) = 3750000
                STANDBY_SPOOL_PERCENT = 0
                 PEER_WINDOW(seconds) = 0
             READS_ON_STANDBY_ENABLED = N

这里只给出了两个member的例子。每个member都有自己的状态。上面的输出项就是所有HADR需要监控的地方。

HADR监控元素说明

db2pd获取出来的关于HADR的信息包含很多细节，基本上与HADR相关的状态、性能等都可以从这些信息里面获得。下表表述了相关监控元素的意义。
表1.HADR监控元素

在上面的监控元素中，最需要关注的是两个方面。一方面是HADR功能的状态。一方面是HADR的性能。HADR的状态主要是观察HADR_STATE，HADR_FLAGS和HADR_CONNECT_STATUS的状态。而HADR的性能主要是观察HADR_LOG_GAP(bytes)和STANDBY_RECV_REPLAY_GAP(bytes)的数值。HADR_LOG_GAP是主备间日志的差距，主要体现在日志传递的性能上，如果太大，可能网络带宽受限，需要改进。STANDBY_RECV_REPLAY_GAP是本地已接受的日志与已回放的日志的差异。主要反映日志回放的性能。如果这个值变大，说明日志回放的速度跟不上日志接受的速度，备机性能有问题。

实战DB2 pureScale集群HADR环境管理维护

下面介绍DB2 pureScale集群HADR环境的管理维护的过程中的一些常用行为。

HADR切换

HADR的切换是指在HADR的备端集群member上运行takeover命令，将备端集群切换为新的主集群并提供数据库连接服务。切换主要包含正常切换和异常切换。

只有在HADR状态是peer的情况下才能正常切换成功。在备集群的任意一个member上运行：

清单14. HADR正常切换

db2 takeover hadr on db TESTDB

如果HADR状态不是peer的情况下，不能进行正常切换，只能强制切换。在备集群的任意一个member上运行：

清单15. HADR异常切换

db2 takeover hadr on db TESTDB by force

HADR设置preferred replay member

PureScale集群的HADR备端replay member可以是任意一个DB2成员节点。用户可以指定其中一个成员节点是preferred replay member角色。这样在同等情况下，DB2需要选择一个member作为replay member的时候，会优先考虑使用preferred replay member。

设置preferred replay member的方式很简单，通过在节点运行start hadr命令，该节点就会成为preferred replay member。

清单16.主集群设置preferred replay member

#在实例用户下，停止HADR：
db2 stop hadr on db TESTDB
#在希望作为preferred replay member的节点上运行start hadr命令：
db2 start hadr on db TESTDB as primary

备集群也是一样通过在目标节点运行start hadr来设置当前节点为preferred replay member。

清单17.备集群设置preferred replay member

在实例用户下，停止数据库激活状态：
db2 deactivate db TESTDB
在希望作为preferred replay member的节点上运行start hadr命令：
db2 start hadr on db TESTDB as standby

HADR滚动宕机维护

DB2 PureScale 在 HADR环境的宕机维护操作可以在不影响DB2数据库提供服务的情况下进行。这种操作称为滚动维护。DB2 pureScale集群中包含多个member节点和2个CF节点。单个member的宕机维护不会影响集群在线。单个CF的维护也会因为有另外一个CF的存在而不影响集群。

如果是在成员主机上执行维护，可以通过db2stop 命令的 QUIESCE
选项来静默成员节点数据库。这种模式不会立刻杀掉当前连接，导致业务有失败交易。而是等待当前事务完成后最终断掉所有这个节点的链接。

清单18.静默数据库

db2stop member member-id quiesce 30

停止该主机前，确保仅成员以主机上的维护为目标。还需要在成员主机上停止此实例，如下所示：

清单19.停止节点实例服务

db2stop instance on host-name

下一步就是将主机变成维护模式。因为oureScale集群依赖于TSA集群软件和GPFS文件系统集群。因此要告诉这两个集群这个节点需要变成维护状态，不要自动响应。在主机上使用root用户发出以下命令将集群管理器置于维护方式：(DB2DIR 表示 DB2 副本的安装位置)

清单20.节点置维护模式

DB2DIR/bin/db2cluster -cm -enter -maintenance
DB2DIR/bin/db2cluster -cfs -enter -maintenance

现在可以完成主机的维护操作，可以重新引导数据库。维护完成后，将主机重新加入集群。使用root用户发出以下命令在主机上退出集群管理器维护方式：

清单21.节点退出维护模式

DB2DIR/bin/db2cluster -cm –exit -maintenance
DB2DIR/bin/db2cluster -cfs -exit -maintenance

最后使用实例用户来启动这个节点，包括实例服务和成员服务：

清单22.启动节点

db2start instance on host-name
db2start member member-id

如果是在CF主机上执行维护，可以通过db2stop 命令加上CF的ID来停止指定CF节点。因为CF是互备的，停止一个CF不会影响交易。CF的切换也非常快，必要的数据已经在内存里实时复制了。使用实例用户停止CF节点：

清单23.停止CF节点

db2stop CF 128
db2stop instance on host-name

与成员节点的维护一样，CF主机也需要设置维护模式，包括TSA集群和GPFS集群。在主机上通过发出以下命令将集群管理器置于维护方式：

清单24.节点置维护模式

DB2DIR/bin/db2cluster -cm -enter -maintenance
DB2DIR/bin/db2cluster -cfs -enter -maintenance

现在可以完成主机的维护操作，可以重新引导数据库。维护完成后，将主机重新加入集群。使用root用户发出以下命令在主机上退出集群管理器维护方式：

清单25.节点退出维护模式

DB2DIR/bin/db2cluster -cm –exit -maintenance
DB2DIR/bin/db2cluster -cfs -exit -maintenance

最后使用实例用户来启动这个节点，包括实例服务和CF服务：

清单26.启动节点

db2start instance on host-name
db2start cf 128

备集群的滚动维护和主集群是一样的。其中备集群里的replay member角色具有高可用性。如果replay member被正常或异常停止， 集群里面其他member会接管HADR的replay工作。

集群增加节点

DB2 pureScale支持横向扩展，也就是可以通过增加成员节点的方式扩展数据库性能。Db2 pureScale集群是支持在线增加节点的。因此在HADR环境也可以在线增加节点来横向扩展。但是需要注意的是必须先在备集群增加节点，然后才能在主集群增加。这个过程中HADR是需要配置，但是数据库是不需要重新备份恢复的。

首先在备集群通过db2iupdt命令来增加节点。这个命令在DB2软件目录的instance目录下，需要root用户来执行。

清单27.备集群增加节点

db2iupdt -add -m <memberhost> -mnet <membernet> db2inst1

然后在备集群需要配置这个成员相关的HADR参数，包括hadr_local_host 和hadr_local_svc。

下一步就是在主机群增加节点和设置hadr_local_host 和hadr_local_svc参数。至此集群就完成了增加节点的操作。最后调整下主备集群的HADR_TARGET_LIST并重启HADR。整个过程并不影响数据库服务。

集群删除节点

DB2 pureScale HADR集群环境下删除一个member节点需要离线，并且需要重新初始化新的HADR环境。首先在主集群停止HADR并删除成员节点。

清单28.停止主集群HADR和实例

db2 stop hadr on db testdb
db2stop force

下一步就可以在root用户下运行db2iupdt命令删除节点。

清单29.主集群删除节点

db2iupdt -drop -m <memberhost> -mnet <membernet> db2inst1

至此主集群已经完成了节点的删除，启动主集群和数据库，恢复服务。很不幸备集群的数据库已经不能使用了，在备集群drop掉数据库，然后和主集群一样，删除一个成员节点。

最后根据最新的主备集群拓扑结构，重新备份恢复数据库，修改HADR参数，搭建新的HADR关系。

HADR应急恢复

DB2 pureScale HADR环境如果发生故障的情况下应急恢复要求如下：数据丢失最少，恢复时间最快。主要方式有强制切换，强制上线和备份恢复等。

强制切换就是在HADR备库激活的情况下直接拉起为主库。

清单30.强制切换

db2 takeover hadr on db TESTDB by force

强制上线就是在HADR备库未激活的情况下直接拉起为主库。

清单31.强制上线

db2 start hadr on db TESTDB as primary by force

备份恢复则是在HADR的两端数据库都丢失的情况下，最后的解决办法。

DB2 pureScale集群HADR环境维护总结
在DB2 pureScale集群HADR环境下的维护工作，既能够利用pureScale集群的高可用性，进行集群内的滚动维护，保持数据库服务不受影响，也可以利用HADR的容灾特性，做集群间的滚动维护。这样即便是维护DB2自身组件，需要整个集群宕机，由于HADR切换迅速的优点，也可以做到数据库服务影响最小。

结束语

现有的DB2 pureScale集群HADR功能与单机版本的HADR功能相比，延续了单机版普通HADR功能的易用性，同时继承了DB2 pureScale集群的高可用性。在数据越来越敏感和安全的信息时代，相信DB2 pureScale集群HADR功能将会被广泛运用在灾备场景。

参考资源 (resources)
• Db2 for Linux UNIX and Windows：获得 DB2 家族产品和特性的描述。
• 参考“IBM DB2 database and SAP software”，了解更多DB2和SAP的相关内容。
• 通过访问 developerWorks 中国 Information Management 专区 的 DB2 purScale 专题获得关于DB2 pureScale集群更多的文章、教程和多媒体课件等学习资源。
• 通过访问 developerWorks 中国 Information Management 专区 的 从 Oracle 迁移到 DB2获得关于“从Oracel迁移到DB2”更多的文章、教程和多媒体课件等学习资源。
• IBM DB2 培训和认证：找到获奖的教员、业界领先的软件、动手实验室等。
• DB2 for Linux, UNIX, and Windows 最佳实践： 获得DB2应用的最佳实践等文章。