关于pureScale集群HADR的特性介绍已经在上一篇文章《实战Db2 purescale集群HADR容灾解决方案上 - 安装配置篇》做了详细介绍。上篇内容也提供了详细的案例去安装和配置HADR功能,包括数据库的客户端驱动如何配置才能自动重路由。
当HADR功能工作后,下一步就是要知道HADR工作的好不好,也就是需要实时监控HADR的状态和性能。例如状态会分哪几种情况,何为正常,HADR的性能如何,有没有导致数据延迟,如果延迟,是发生在什么地方,等等。然后在这种复杂的环境下,维护类操作该怎么处理,需要遵循什么流程。本篇文章将详细阐述这些问题。
关于pureScale HADR环境的监控和普通的单机版监控类似,都可以通过db2pd工具来实现。但是由于集群环境的特殊性,需要监控的内容和单机版DB2有所区别。db2pd工具会返回当前节点的HADR信息。
因为DB2 pureScale是多节点的集群架构,所以在主集群建议结合使用db2_all命令和db2pd命令来返回所有节点的HADR状态信息,备集群在replay member上使用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需要监控的地方。
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环境的管理维护的过程中的一些常用行为。
HADR的切换是指在HADR的备端集群member上运行takeover命令,将备端集群切换为新的主集群并提供数据库连接服务。切换主要包含正常切换和异常切换。
只有在HADR状态是peer的情况下才能正常切换成功。在备集群的任意一个member上运行:
db2 takeover hadr on db TESTDB
如果HADR状态不是peer的情况下,不能进行正常切换,只能强制切换。在备集群的任意一个member上运行:
db2 takeover hadr on db TESTDB by force
PureScale集群的HADR备端replay member可以是任意一个DB2成员节点。用户可以指定其中一个成员节点是preferred replay member角色。这样在同等情况下,DB2需要选择一个member作为replay member的时候,会优先考虑使用preferred replay member。
设置preferred replay member的方式很简单,通过在节点运行start hadr命令,该节点就会成为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。
在实例用户下,停止数据库激活状态:
db2 deactivate db TESTDB
在希望作为preferred replay member的节点上运行start hadr命令:
db2 start hadr on db TESTDB as standby
DB2 PureScale 在 HADR环境的宕机维护操作可以在不影响DB2数据库提供服务的情况下进行。这种操作称为滚动维护。DB2 pureScale集群中包含多个member节点和2个CF节点。单个member的宕机维护不会影响集群在线。单个CF的维护也会因为有另外一个CF的存在而不影响集群。
如果是在成员主机上执行维护,可以通过db2stop 命令的 QUIESCE
选项来静默成员节点数据库。这种模式不会立刻杀掉当前连接,导致业务有失败交易。而是等待当前事务完成后最终断掉所有这个节点的链接。
db2stop member member-id quiesce 30
停止该主机前,确保仅成员以主机上的维护为目标。还需要在成员主机上停止此实例,如下所示:
db2stop instance on host-name
下一步就是将主机变成维护模式。因为oureScale集群依赖于TSA集群软件和GPFS文件系统集群。因此要告诉这两个集群这个节点需要变成维护状态,不要自动响应。在主机上使用root用户发出以下命令将集群管理器置于维护方式:(DB2DIR 表示 DB2 副本的安装位置)
DB2DIR/bin/db2cluster -cm -enter -maintenance
DB2DIR/bin/db2cluster -cfs -enter -maintenance
现在可以完成主机的维护操作,可以重新引导数据库。维护完成后,将主机重新加入集群。使用root用户发出以下命令在主机上退出集群管理器维护方式:
DB2DIR/bin/db2cluster -cm –exit -maintenance
DB2DIR/bin/db2cluster -cfs -exit -maintenance
最后使用实例用户来启动这个节点,包括实例服务和成员服务:
db2start instance on host-name
db2start member member-id
如果是在CF主机上执行维护,可以通过db2stop 命令加上CF的ID来停止指定CF节点。因为CF是互备的,停止一个CF不会影响交易。CF的切换也非常快,必要的数据已经在内存里实时复制了。使用实例用户停止CF节点:
db2stop CF 128
db2stop instance on host-name
与成员节点的维护一样,CF主机也需要设置维护模式,包括TSA集群和GPFS集群。在主机上通过发出以下命令将集群管理器置于维护方式:
DB2DIR/bin/db2cluster -cm -enter -maintenance
DB2DIR/bin/db2cluster -cfs -enter -maintenance
现在可以完成主机的维护操作,可以重新引导数据库。维护完成后,将主机重新加入集群。使用root用户发出以下命令在主机上退出集群管理器维护方式:
DB2DIR/bin/db2cluster -cm –exit -maintenance
DB2DIR/bin/db2cluster -cfs -exit -maintenance
最后使用实例用户来启动这个节点,包括实例服务和CF服务:
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用户来执行。
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并删除成员节点。
db2 stop hadr on db testdb
db2stop force
下一步就可以在root用户下运行db2iupdt命令删除节点。
db2iupdt -drop -m <memberhost> -mnet <membernet> db2inst1
至此主集群已经完成了节点的删除,启动主集群和数据库,恢复服务。很不幸备集群的数据库已经不能使用了,在备集群drop掉数据库,然后和主集群一样,删除一个成员节点。
最后根据最新的主备集群拓扑结构,重新备份恢复数据库,修改HADR参数,搭建新的HADR关系。
DB2 pureScale HADR环境如果发生故障的情况下应急恢复要求如下:数据丢失最少,恢复时间最快。主要方式有强制切换,强制上线和备份恢复等。
强制切换就是在HADR备库激活的情况下直接拉起为主库。
db2 takeover hadr on db TESTDB by force
强制上线就是在HADR备库未激活的情况下直接拉起为主库。
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 条评论
2018-05-29 11:36
2018-05-10 23:16