HADR架构下,备机不重放日志?

db2 10.1.3版本备机重放日志动作,忽然停止,导致standby 备机活动日志目录文件系统满。使用db2pd -hadr 查看各项指标正常。在没有办法的情况下,进行了备机实例和数据库重启,备机就可以继续重放日志。问题是如何进行此类问题的有效监控,达到提前预警。第二出现此类问题的合理有...显示全部

db2 10.1.3版本
备机重放日志动作,忽然停止,导致standby 备机活动日志目录文件系统满。使用db2pd -hadr 查看各项指标正常。
在没有办法的情况下,进行了备机实例和数据库重启,备机就可以继续重放日志。
问题是如何进行此类问题的有效监控,达到提前预警。
第二出现此类问题的合理有效处理方法,以及是否需要后续升级等措施

收起

返回冯岩的回答

冯岩冯岩  数据库管理员 , 银行
zsk19872010yinxinwuwenpin等赞同了此回答

您好,您先简单讲一下您的 HADR 环境配置(HADR_SYNCMODE等等)和业务负载情况,方便我们更加清晰地了解下问题,具体问题具体分析。
我先问几个问题啊:
首先,“ hadr standby 的 log replaying 突然停止” 问题,您是如何发现的?
当时的 diag日志,有什么线索吗?
此类问题发生前后,primary 是否存在大量并发 DML,DDL等需要记录日志操作?
此类问题是否经常发生,并伴随些规律性特征?


根据您最新的问题描述:“现象类似于standby库hang” ,我认为您应该在下次问题发生时,抓一下DB2 latch、log replay相关EDU 的堆栈信息,还有 trace信息,看看什么问题。可以写个触发脚本,当 active log 目录文件系统使用急速激增时,触发脚本收集这些信息。然后,根据这些信息判断 hang的原因,或发给 IBM 解决。

 2019-04-10
  • hadr standby 的 log replaying 突然停止,描述为replay动作异常,比较好,现象类似于standby库hang,描述装态这个可能不准确。 日志不重放,我们并没有第一时间发现,是备机的active log 目录文件系统增长到几百G, 从文件系统使用率层面才暴露出来的,顺着文件系统使用率的线索,查看数据库,才发现日志堆积,日志的个数越来越多。而主机primary还在正常的运行,而备机的日志不重放,所以日志堆积的很多。
    2019-04-10
  • [此评论已删除]
    2019-04-10
  • hadr 同步模式是近同步。在diag日志中,没有线索。问题发生时,使用db2pd收集了app,session, sql,db2pd -hadr , 数据库日志相关的配置value,以及目录下日志个数,first active log等情况。没有明显的指向。
    2019-04-10
  • 也就是说 diag 日志中并没有发现问题发生前后 warning、error、critical等有价值和问题指向的信息可供参考?是这样吧? “现象类似于standby库hang” 这个信息很有价值! 对了,你们那里类似问题发生的多吗?是否方便上传部分diag文件分析下?
    2019-04-10

回答者

冯岩数据库管理员, 银行

回答状态

  • 发布时间:2019-04-10
  • 关注会员:2 人
  • 回答浏览:468
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30