DMDSC 故障处理

DMDSC 集群出现数据库实例、或者节点硬件故障时,dmserver 的 Voting disk 心跳信息不再更新,DMCSS 一旦监控到 dmserver 发生故障,会马上启动故障处理(参考第 5 章 DMCSS 介绍),各节点 dmserver 收到故障处理命令后,启动故障处理流程。

在 DMDSC 故障处理机制下,一旦产生节点故障,登录到故障节点的所有连接将会断开,所有未提交事务将被强制回滚;活动节点上的用户请求可以继续执行,但是一旦产生节点间信息传递(比如:向故障节点发起 GBS/LBS 请求、或者发起 remote read 请求),当前操作就会被挂起;在 DMDSC 故障处理完成后,这些被挂起的操作可以继续执行。也就是说,DMDSC 产生节点故障时,活动节点上的所有连接会保留,正在执行的事务可能被阻塞一段时间,但最终可以正常完成,不会被强制回滚,也不会影响结果的正确性。

DMDSC 环境 dmserver 故障处理主要包括以下工作:

  1. 暂停所有会话线程、工作线程、日志刷盘线程、检查点线程等,避免故障处理过程中产生并发错误;
  2. 收集所有活动节点的 BUFFER,丢弃无效数据页,获取最新数据页和需要重做故障节点 REDO 日志的数据页信息,并在排除故障节点后重新构造 LBS/GBS 信息;
  3. 重做故障节点 REDO 日志;
  4. 收集所有节点事务信息,重新构造锁对象,并重构相应的 LLS/GLS/LTV/GTV 系统;
  5. 如果配置有 VIP,进行必要的 VIP 配置操作;
  6. 控制节点执行故障节点活动事务回滚和故障节点已提交事务修改的 PURGE 操作。

DMDSC 故障处理分为两个阶段;第一阶段由所有活动节点共同参与,进行全局的信息收集、重构;第二阶段由控制节点执行,将故障节点的活动事务回滚、并 PURGE 故障节点已提交事务的修改。在第一阶段执行期间,数据库实例不提供数据库服务,所有用户请求将被挂起。在第二阶段操作之前,会唤醒所有活动节点,正常提供数据库服务。也就是说故障处理第二阶段的操作与正常的数据库操作在系统内部同时进行。但在第二阶段执行完成之前,DMDSC 故障处理仍然没有真正结束,在此期间,不能处理节点重加入,也不能处理新的节点故障,如果有新的节点故障会主动中止所有节点。

注意

1.通常意义上讲的故障处理,包含故障检测和故障处理两部分。
2.故障检测时间由DCR_GRP_DSKCHK_CNT决定。
3.影响故障处理时间的因素比较多,主要包括:故障节点Redo日志数量、修改涉及的数据页多少、需要ROLLBACK、PURGE的事务数,以及活动节点Buffer使用情况等。

微信扫码
分享文档
扫一扫
联系客服