孔再华
作者孔再华2018-05-10 13:48
数据库运维工程师, 中国民生银行

实战Db2 purescale集群HADR容灾解决方案 - 监控维护篇

字数 9942阅读 5384评论 2赞 5

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监控元素
微信截图_20180510114915.png

微信截图_20180510114915.png

微信截图_20180510115331.png
微信截图_20180510115331.png

微信截图_20180510120517.png
微信截图_20180510120517.png

微信截图_20180510120542.png
微信截图_20180510120542.png

微信截图_20180510133937.png
微信截图_20180510133937.png

微信截图_20180510134134.png
微信截图_20180510134134.png

微信截图_20180510134035.png
微信截图_20180510134035.png

在上面的监控元素中,最需要关注的是两个方面。一方面是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应用的最佳实践等文章。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论2 条评论

#wuwenpin软件开发工程师, 南京
2018-05-29 11:36
学习一下!
#1301664724qq系统工程师, IBM
2018-05-10 23:16
不错的分享,谢谢!!!
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30