DM集群架构总结

整体概述

DM数据守护包括以下几个主要组件

日志组件：包括日志FLUSH线程、日志归档线程、日志Apply线程三个线程

MAL系统：负责将远程归档传输到备库的replay service

数据守护进程：接收实例先关状态信息，实现主备节点之间的状态同步，并和监控进程进行交互

监控进程：监控集群各个节点状态和同步情况，在必要的时候通过守护进程进行切换操作

下面针对各个组件进行一一介绍

一、日志组件

1、日志组件相关基本概念

redo-log(重做日志) 是一组物理文件，数据库中添加、删除、修改对象，或者改变数据，数据库都会按照特定的格式，将这些操作执行的结果写入到当前的重做日志文件中。事务提交时数据先写入redolog,后写入数据文件

archivelog(归档日志) redo-log日志是循环使用的，当redo-log被写满后，数据库会根据检查点覆盖之前的内容。覆盖之前redo-log中的数据复制到归档日志中。

KEEP_PKG    主库的RLOG_PKG日志通过实时归档机制发送到备库后，备库将最新收到的RLOG_PKG保存在内存中，不马上启动重演，这个 RLOG_PKG 我们称之为 KEEP_PKG。而即时归档不存在这种机制

RLOG_PKG Redo 日志包是 DM 数据库批量保存物理事务产生的 Redo 日志的数据单元，以物理事务 PTX 为单位保存日志，一个日志包内可连续保存一个或多个 PTX。物理事务提交时将 Redo 日志写入到日志包中，在数据库事务提交或日志包被写满时触发日志刷盘动作。DM 数据守护系统中，主库以RLOG_PKG 为最小单位发送 Redo 日志到备库。

2、日志组件相关线程

日志归档线程

归档模式	描述
实时归档（REALTIME）	主库在 Redo 日志（RLOG_PKG）写入redo-log文件前，将 Redo日志发送到备库。实时归档也可以支持读写分离集群(访问)
即时归档（TIMELY）	主库在 Redo 日志（RLOG_PKG）写入redo-log文件后，将 Redo日志发送到备库。
异步归档（ASYNC）	在设定的时间点或者每隔设定时间，启动归档 REDO 日志发送。通过 MAL系统，获取远程服务器的当前 LSN，生成发送归档 REDO 日志任务，加入任务队列。

日志APPLY线程

应用模式	描述
高性能 ARCH_WAIT_APPLY=0	备库收到主库发送的 Redo 日志后，马上响应主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。
事务一致 ARCH_WAIT_APPLY=1	备库收到主库发送的 Redo 日志，并重演完成后再响应主库。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，查询结果都满足 READ COMMIT 隔离级要求。

3、日志的归档模式

实时归档 

redo apply方式采用高性能模式即ARCH_WAIT_APPLY=0 这是实时归档的默认模式

①主库触发联机 Redo 日志写操作

②MAL系统先将 RLOG_PKG 发送到备库

③备库接收后进行合法性校验（包括日志是否连续、备库状态是否 Open 等），不合法则返回错误信息，

④合法则作为 KEEP_PKG 保留在内存中，原有 KEEP_PKG 的 Redo 日志加入 Apply 任务队列进行 Redo 日志重演

⑤并响应主库日志接收成功。

⑥redo写入联机日志文件

即时归档

高性能模式即ARCH_WAIT_APPLY=0 是即时归档的推荐模式

 

①主库生成联机 Redo 日志

②将 RLOG_PKG 发送到备库，备库接收后进行合法性校验（包括日志是否连续、备库状态是否 Open 等），不合法则返回错误信息

③合法后，判断模式，是否响应主库，RLOG_PKG直接加入到 Apply 任务系统，启动 Redo 日志重演。如果是事务一致性模式，最后重演完响应主库

二、守护进程

DM数据守护集群 守护进程：（dmwatcher）是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上

 

区分方式	包含内容
守护类型	本地守护和全局守护
守护模式	故障自动切换和故障手动切换
守护状态	守护进程的状态主要类型是open和startup，中间状态包括Switchover、Failover、Recovery、Confirm等

本地守护： 实例主动主动推送实例信息到守护进程，信息包括主动推送：实例进程 ID、实例名、数据库模式、数据库状态、LSN、MAL链路状态等 守护进程通过INST_ERROR_TIME参数判定是否超时 通过INST_AUTO_RESTART参数判定是否自动启动服务

 

全局守护： 在本地守护的基础上增加了守护进程之间以及守护进程和监视器之间的信息推送和接收监视器命令。 守护进程主动推送守护进程信息和实例信息 通过DW_ERROR_TIME判定某个守护进程是否超时 配置确认监视器可以实现守护进程异常情况下的实例状态自动切换

主备和读写分离集群全局守护结构

 

守护进程的状态 主要是状态是 startup 和open 中间状态是对应集群故障的不同处理流程 比如自动切换模式下备库故障时：主库守护进程现将备库守护进程切换到confrim状态，然后再监视器确认之后，再将备库守护进程置为FAILOVER，备库归档失效 自动切换模式下进程状态由监视器负责变更，手动切换模式下需要手动介入

 

 

守护进程常见故障处理流程

列举几种常见故障下守护进程状态转换流程 处理优先级 failover>备库异常>故障恢复recovery 故障或异常情况下状态

 备库自动切换场景

 

 脑裂判断规则 判断方式：主库本地和远程库的openhistory进行比较 主库和远程库相等，有primary状态库则判断为主库，无则需要比较apply信息 远程库包含在本地库中远程库的open历史<=主库第一条 Open 记录项 远程库的守护进程再继续根据模式、状态信息确定下一步动作，最终可以将其作为备库重加入守护系统 本地库包含在远程库中并且 远程库的第一条open记录>=本地库记录 本地库的守护进程再继续根据模式、状态信息确定下一步动作，最终可以将其作为备库重加入守护系统 本地库和远程库不相等，也没有包含关系 需要需要人工介入 SYSOPENHISTORY 表最多只维护 128 条 Open 记录，达到 128 条以 后会从第一条记录开始自动覆盖，并依次往后循环使用。在主备库的数据差异很大的情况下，备库的最后一条 Open 记录有可能在主库上已经被覆盖掉，覆盖之后需要人工介入

介绍通过监视器手动互换主备角色和在主备故障情况下手动指定主库的方法

使用前，必须先输入login 命令 登录

异常切换

choose takeover GDW1_01

takeover GDW1_01.DW1_01B

正常切换

choose switchover grp1

switchover  grp1.PROD01

集群模式下常见的连接客户端配置

连接客户端配置

1.修改dm_svc.conf内容 TIME_ZONE=(480) LANGUAGE=(cn) DMHA=(192.168.100.100:5236,192.168.100.101:5236) #服务配置 [DMHA] SWITCH_TIMES=(3)  SWITCH_INTERVAL=(1000)  LOGIN_MODE=(1) 2.修改url连接串增加 jdbc:dm://DMHA 如下： static String dname = "dm.jdbc.driver.DmDriver"; static String url = "jdbc:dm://DMHA"; 以“[服务名]”开头，可配置除了服务名外的所有配置项。服务配置区中的配置优先级高于全局配置区（服务配置区的相同配置项会覆盖全局配置区对应的配置项）。 LOGIN_MODE：指定优先登录的服务器模式。0：优先连接 PRIMARY 模式的 库，NORMAL 模式次之，最后选择 STANTBY 模式；1：只连接主库；2：只连接备库；3：优先连接 STANDBY 模式的库， PRIMARY 模式次之，最后选择 NORMAL 模式；4：优先连接 NORMAL 模式的库，PRIMARY 模式次之，最后选择STANDBY 模式 。 SWITCH_TIMES:以服务名连接数据库时，若未找到符合条件的库成功建立连接，将尝试遍历服务名中库列表的次数。有效值范围1~9223372036854775807，默认值为1，可以设置至少3次用来避免由于网卡的波动照成数据库连接测频繁切换 SWITCH_INTERVAL ：在服务器之间切换的时间间隔，单位为毫秒，有效值范围 1~9223372036854775807。与参数SWITCH_TIMES、EP_SELECTOR配合使用，EP_SELECTOR设置为0，等待SWITCH_INTERVAL后会切换尝试连接下一个服务器,EP_SELECTOR设置为1，等待SWITCH_INTERVAL后会继续尝试连接该服务器，直到SWITCH_TIMES次再切换下一个服务器.