二 主备库配置文件说明

与 DM 数据守护相关的配置文件包括：

1、数据库配置文件 dm.ini

2、数据库控制文件 dm.ctl

3、MAL 配置文件 dmmal.ini

4、Redo 日志归档配置文件 dmarch.ini

5、守护进程配置文件 dmwatcher.ini

6、守护进程控制文件 dmwatcher.ctl

7、监视器配置文件dmmonitor.ini

8、定时器配置文件 dmtimer.ini

9、MPP 控制文件 dmmpp.ctl 等等

各配置文件的存放路径：

1. dm.ini 存放目录没有限制，一般直接放在数据库目录中。

2. dmmal.ini 、 dmarch.ini 、 dmtimer.ini 存放 目 录 由 dm.ini 的CONFIG_PATH 配置项指定

3. dmwatcher.ini 存放目录没有限制，一般和 dm.ini 存放同一个目录。

4. dmmonitor.ini 存放目录没有限制，一般和 dm.ini 存放同一个目录。

5. dm.ctl 存放目录由 dm.ini 的 CTL_PATH 配置项指定。

6. dmmpp.ctl 、dmwatcher.ctl 存放目录由 dm.ini 的 SYSTEM_PATH 配置项指定。

2.1 dm.ini

dm.ini是数据库配置文件。

2.2 dmmal.ini

dmmal.ini是 MAL 配置文件。需要用到 MAL 环境的实例，所有站点 dmmal.ini 需要保证严格一致。

2.3 dmarch.ini

dmarch.ini是 Redo 日志归档配置文件。

2.4 dmwatcher.ini

dmwatcher.ini是守护进程配置文件。

2.5 dmwatcher.ctl

除了配置为 Local 守护类型的实例外，其他实例的库目录下都需要有守护进程控制文件dmwatcher.ctl，且初始配置时同一个守护进程组的控制文件必须相同。

该控制文件由 dmctlcvt 工具根据 dmwatcher.ini 转化生成。控制文件中有一个随机的 tguid 值，每次调用 dmctlcvt 生成的 tguid 都不同，因此初始搭建环境时，同一个组只能通过 dmctlcvt 工具生成一次，并分别拷贝到各数据库目录下，不能采用分别生成的方式。

dmwatcher.ctl按照dmwatcher.ini 中配置的组名分别生成到各自的目录下，同一个守护进程组需要使用同一份控制文件。同一个组使用了不同的 dmwatcher.ctl 控制文件将造成组分裂。

dmctlcvt工具用法格式如下：

[dmdba@dm3~]$ dmctlcvt help

DMCTLCVTV7.6.0.171-Build(2019.07.02-109059)ENT

格式: ./dmctlcvt KEYWORD=value

注意: 控制文件名称必须指定为dm.ctl、dmmpp.ctl或dmwatcher.ctl

关键字              说明

--------------------------------------------------------------------------------

TYPE               1 转换控制文件为文本文件（源文件路径中控制文件名称必须是dm.ctl或dmmpp.ctl）

                    2 转换文本文件为控制文件（目标文件路径中控制文件名称必须是dm.ctl或dmmpp.ctl）

                    3 转换文本文件为守护进程控制文件（目标文件路径中不需要指定控制文件名称，会自动生成）

                    4 转换守护进程控制文件为文本文件（源文件路径中控制文件名称必须是dmwatcher.ctl）

SRC                 源文件路径

DEST                目标文件路径

DCR_INI             dmdcr.ini文件路径

HELP                打印帮助信息

示例：

./dmctlcvtTYPE=1 SRC=/opt/dmdbms/data/dameng/dm.ctlDEST=/opt/dmdbms/data/dameng/dmctl.txt

./dmctlcvtTYPE=2 SRC=/opt/dmdbms/data/dameng/dmctl.txtDEST=/opt/dmdbms/data/dameng/dm.ctl

./dmctlcvtTYPE=3 SRC=/opt/dmdbms/data/dameng/dmwatcher.txt DEST=/opt/dmdbms/data/dameng

./dmctlcvtTYPE=4 SRC=/opt/dmdbms/data/dameng/dmwatcher.ctlDEST=/opt/dmdbms/data/dameng/dmwatcher_ctl.txt

[dmdba@dm3~]$

生成 ctl 文件

需要指定 dmwatcher.ini 路径和文件输出路径，生成的 dmwatcher.ctl 按组名分开存放，同一组的所有实例使用同一个 ctl 文件。

参考命令如下：

./dmctlcvt TYPE=3 SRC=/dm7/data/DAMENG/dmwatcher.iniDEST=/dm7/data

解析 ctl 文件

可将 dmwatcher.ctl 内容读出到 txt 文件中，方便查看内容。

参考命令如下：

./dmctlcvt TYPE=4SRC=/dm7/data/DAMENG/dmwatcher.ctl DEST=/dm7/data/DAMENG/dmwatcher.txt

2.6 dmmonitor.ini

dmmonitor.ini是监视器配置文件。

2.7 dmtimer.ini

dmtimer.ini用于配置定时器，可记录异步备库的定时器信息。dmtimer.ini 的配置项见下表，其中项目名称就是定时器名称。表中参数与创建定时器的过程 SP_ADD_TIMER()参数用法相同。

例 1，配置名称为“TIMER_01”的定时器，TYPE = 1，开始时间为 2016-02-22 17:30:00，只执行一次。

[TIMER_01]
TYPE = 1
FREQ_MONTH_WEEK_INTERVAL = 0
FREQ_SUB_INTERVAL = 0
FREQ_MINUTE_INTERVAL = 0
START_TIME = 00:00:00
END_TIME = 00:00:00
DURING_START_DATE = 2016-02-22 17:30:00
DURING_END_DATE = 2016-02-22 17:30:30
NO_END_DATE_FLAG = 0
DESCRIBE = RT TIMER
IS_VALID = 1

例 2：配置名称为“TIMER_01”的定时器，TYPE = 2，每天 01:00:00 触发。

[TIMER_01]
TYPE = 2
FREQ_MONTH_WEEK_INTERVAL = 1
FREQ_SUB_INTERVAL = 0
FREQ_MINUTE_INTERVAL = 0
START_TIME = 01:00:00
END_TIME = 01:00:10
DURING_START_DATE = 2016-02-11 17:36:09
DURING_END_DATE = 9999-12-31 23:59:59
NO_END_DATE_FLAG = 1
DESCRIBE = RT TIMER
IS_VALID = 1

2.8 端口配置关系说明

对上述 ini 文件中的各个端口之间的对应关系说明如下：

2.8.1 dm.ini

dm.ini 中端口相关的有两个配置项：PORT_NUM、DW_PORT。

PORT_NUM

是数据库实例的监听端口，监听用户的连接请求，dmmal.ini中的[MAL_INST_NAME: MAL_INST_PORT]要与 dm.ini 中的[INSTANCE_NAME: PORT_NUM]保持一致。

DW_PORT

是守护系统中，数据库监听守护进程连接请求的端口，由守护进程主动建立到数据库的TCP连接，这个端口只用于数据库和守护进程之间的消息交互使用。

例如，以主库GRP1_RT_A，备库 GRP1_RT_B 为例，来说明如何使用 PORT_NUM、DW_PORT。

主库 GRP1_RT_A 的 dm.ini：

#这里只列举端口相关的参数
INSTANCE_NAME = GRP1_RT_A
PORT_NUM = 5236 #数据库实例监听端口
DW_PORT = 5237 #守护进程监听端口

备库 GRP1_RT_B 的 dm.ini：

#这里只列举端口相关的参数
INSTANCE_NAME = GRP1_RT_B
PORT_NUM = 6236 #数据库实例监听端口
DW_PORT = 6237 #守护进程监听端口

2.8.2 dmmal.ini

dmmal.ini 中每个实例都有一个单独的 mal 配置项，每个实例中有三个端口相关的配置：MAL_PORT、MAL_INST_PORT、MAL_DW_PORT。

MAL_PORT

MAL 监听端口，用于创建 MAL 链路，同一个实例的 MAL 配置项中，MAL_PORT 不能和实例 dm.ini 中的两个端口相同，避免端口绑定冲突。

MAL_INST_PORT

MAL 配置项中，MAL_INST_NAME 实例的监听端口，和实例 dm.ini 的 PORT_NUM 值相同。

MAL_DW_PORT

守护进程监听端口，其他守护进程或监视器使用 MAL_HOST +MAL_DW_PORT 创建 TCP连接。监视器配置文件dmmonitor.ini 中，MON_DW_IP 就是一组MAL_HOST: MAL_DW_PORT。

例如，这里以主库GRP1_RT_A，备库 GRP1_RT_B 为例进行说明。

MAL_CHECK_INTERVAL = 5
MAL_CONN_FAIL_INTERVAL = 5

[MAL_INST1]
MAL_INST_NAME = GRP1_RT_A
MAL_HOST = 192.168.0.141
MAL_PORT = 5238
MAL_INST_HOST = 192.168.1.131
MAL_INST_PORT = 5236 #数据库实例监听端口，对应 dm.ini 中的 PORT_NUM
MAL_DW_PORT = 5239 #守护进程监听端口

[MAL_INST2]
MAL_INST_NAME = GRP1_RT_B
MAL_HOST = 192.168.0.142
MAL_PORT = 6238
MAL_INST_HOST = 192.168.1.132
MAL_INST_PORT = 6236 #数据库实例监听端口，对应 dm.ini 中的 PORT_NUM
MAL_DW_PORT = 6239 #守护进程监听端口

2.8.3 dmwatcher.ini

守护进程启动时，需要获取远程实例对应的配置项信息，创建到远程守护进程的 TCP连接，这些信息通过 INST_INI 配置项来获取。

守护进程从 INST_INI路径找到并读取 dm.ini、dmmal.ini、dmarch.ini，综合各个配置项得到远程守护进程的 IP、端口等信息并建立连接。

2.8.4 dmmonitor.ini

监视器配置项中以守护进程组为单位，通过 MON_DW_IP 配置到每组的所有守护进程的IP 和端口信息。

配置格式为：“守护进程 IP地址:守护进程 TCP 端口”。

其中守护进程 IP 地址和 dmmal.ini 中的 MAL_HOST 保持一致，守护进程 TCP 端口和 dmmal.ini 中的 MAL_DW_PORT 保持一致。

dmmal.ini 中配置有多少个 IP 和PORT，dmmonitor.ini 就需要配置多少个对应的 “IP:PORT”信息，否则会无法接收到消息。

例如，这里以监控主库GRP1_RT_A，备库 GRP1_RT_B 说明：

#这里只对 IP/端口信息举例说明
[GRP1]
MON_INST_OGUID = 82379
#IP 和 PORT 信息和 dmmal.ini 中的 MAL_HOST 和 MAL_DW_PORT 配置项一致
MON_DW_IP = 192.168.0.141:5239
MON_DW_IP = 192.168.0.142:6239

2.9 服务名配置

配置 DM 数据守护，一般要求配置连接服务名，以实现故障自动重连。连接服务名可以在 DM 提供的 JDBC、DPI 等接口中使用，连接数据库时指定连接服务名，接口会随机选择一个 IP 进行连接，如果连接不成功或者服务器状态不正确，则顺序获取下一个 IP 进行连接，直至连接成功或者遍历了所有 IP。

可以通过编辑dm_svc.conf 文件，配置连接服务名。dm_svc.conf 配置文件在 DM 安装时生成，Windows 平台下位于%SystemRoot%/system32 目录，Linux 平台下位于/etc 目录。

连接服务名格式：

SERVERNAME=(IP[:PORT],IP[:PORT],……)

dm_svc.conf 文件，常用配置项目说明：

SERVERNAME: 连接服务名，用户通过连接服务名访问数据库。
IP: 数据库所在的IP 地址，如果是 IPv6 地址，为了区分端口，需要用[]封闭 IP 地址。
PORT: 数据库使用的TCP 连接端口，可选配置，不配置则使用连接上指定的端口。
LOGIN_MODE: 服务名方式登录，始终会优先登录主库；LOGIN_MODE 表示是否仅登录主库或者备库，可以配置为 0、1 或 2。0 表示优先登录主库，没有可用主库情况下登录备库；1 表示不登录 Standby 模式的库，如果系统中只有 Standby 模式的库，登录失败并报错；2 表示仅登录 Standby 模式的库。默认值为 0。
SWITCH_TIME: 检测到数据库实例故障时，接口在服务器之间切换的次数；超过设置次数没有连接到有效数据库时，断开连接并报错。有效值范围 1~9223372036854775807，默认值为 3。
SWITCH_INTERVAL: 表示在服务器之间切换的时间间隔，单位为毫秒，有效值范围1~9223372036854775807，默认值为 200。

例如，这里我们配置一个名为dw_svc 的连接服务名，使用 dw_svc 连接数据守护中的数据库，即可实现故障自动重连。

dw_svc=(192.168.1.131:5236,192.168.1.132:5236)
LOGIN_MODE =(1)
SWITCH_TIME=(3)
SWITCH_INTERVAL=(1000)

三 监视器

3.1 监视器概述

监视器（dmmonitor）是基于监视器接口实现的一个命令行工具，是 DM 数据守护系统的重要组成部分。

通过监视器，可以监控数据守护系统的运行情况，获取主备库状态、守护进程状态、以及主备库数据同步情况等信息。同时，监视器（dmmonitor）还提供了一系列命令来管理数据守护系统。

监视器的基本作用如下：

1）监控数据守护系统

接收守护进程发送的消息，显示主、备数据库状态变化，以及故障切换过程中，数据库模式、状态变化的完整过程。

2）管理数据守护系统

用户可以在监视器上输入命令，启动、停止守护进程的监控功能，执行主备库切换、备库故障接管等操作。

3）确认状态信息

用于故障自动切换的数据守护系统中，主、备库进行故障处理之前，需要通过监视器进行信息确认，确保对应的备库或者主库是真的产生异常了，避免主备库之间网络故障引发脑裂。

4）发起故障自动接管命令

用于故障自动切换的数据守护系统中，主库发生故障时，挑选符合接管条件的备库，并通知备库执行接管操作。

注意：

对于实时主备和读写分离集群，监视器只允许配置一个守护进程组；MPP 主备允许配置多组，并且要求这些组的主库必须是同一套 MPP 系统；

对于本地守护类型，允许和实时主备/读写分离集群/MPP 主备配置到同一组作为异步备库，如果不作为某个实例的异步备库，只是普通的单机配置为本地守护类型，则需要单独成组，并且监视器也不允许配置多组。

3.2 监视器类型

监视器支持两种运行模式：监控模式和确认模式。监视器运行模式由配置文件（dmmonitor.ini）的 MON_DW_CONFIRM 参数来确定。MON_DW_CONFIRM 参数的默认值是 0，表示监控模式；MON_DW_CONFIRM 参数值为 1 时，表示监视器运行在确认模式下。

为了区分监视器的两种模式，我们将运行在确认模式下的监视器称为确认监视器。

2.1 监控模式

一个数据守护系统中，最多允许同时启动 10 个监视器，所有监视器都可以接收守护进程消息，获取守护系统状态。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。

2.2 确认模式

和监控模式一样，确认监视器接收守护进程消息，获取数据守护系统状态，也可以执行各种监控命令。区别在于，除了具备监控模式监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。此外，一个数据守护系统中，只能配置 1 个确认监视器。故障自动切换模式的数据守护系统，必须部署一个确认监视器，否则在出现实例故障时，会导致数据库服务中断。

3.3 状态确认

故障自动切换模式数据守护系统中，主库守护进程监测到备库故障时，需要向确认监视器求证，确认备库是真的故障了，再启动故障处理流程将归档失效，避免引发脑裂。比如，主库网络故障，主库直接将归档失效继续以 Primary 模式提供服务；同时，确认监视器认为主库故障，将备库切换为Primary 模式，守护进程组中同时出现多个主库，引发脑裂。

状态确认只对故障自动切换数据守护系统有效，手动切换模式下，不需要状态确认。主库守护进程在满足一定条件时，会切换到 Confirm 状态，向确认监视器进行求证。

主库守护进程切换到Confirm 之后，根据不同的场景决定是否切换为 Failover 状态并启动故障处理流程，这里列举出几种常见的场景处理（注意前提是主库的守护进程已经处于 Confirm 状态）：

1、主库网络故障，主库到备库、主库到确认监视器的连接异常。这种情况下主库守护进程，一直保持 Confirm 状态，不会启动故障处理流程。

2、备库故障或者备库网络故障，主库守护进程会切换为 Failover 状态，启动故障处理流程。

3、主备库之间网络故障，但与确认监视器之间的网络正常，确认监视器确认主库满足Failover 执行条件，主库守护进程会切换为 Failover 状态，启动故障处理流程，否则主库守护进程一直保持在 Confirm 状态。

3.4 自动接管

故障自动切换模式下，确认监视器检测到主库故障后，根据收到的主备库 LSN、归档状态、MAL 链路状态等信息，确定一个接管备库，并将其切换为主库。确认监视器启动自动接管流程的主要场景有三种，任何一种都会导致备库自动接管。场景如下：

1、主库数据库实例异常终止，主库守护进程正常。

2、主库硬件故障、或者数据库实例和守护进程同时故障。

3、主库网络故障，主备库之间、主库与监视器之间连接异常。

若想实现备库自动接管，主库，归档状态，备库都必须符合一定条件才行。条件如下：

主库：

主库是 Primary 模式、Open状态时，产生故障。

主库守护进程故障，故障前是 Open/Recovery 状态。

故障主库与接管备库和确认监视器之间的 MAL 链路断开。

归档状态：

故障主库到接管备库的归档状态为 Valid。

备库：

接管备库是 Standby 模式、Open 状态；接管备库的 dmwatcher.ctl 控制文件状态为 Valid；故障主库和接管备库的 dmwatcher.ctl 控制文件相同。

如果主库故障前，正在执行Switchover/Takeover 等命令，则备库不会自动接管，需要人工干预。

确认监视器要求一开始就启动，保证出现故障情况时，确认监视器已经收到了故障主库或备库的历史消息，否则会因为条件不足无法自动处理，需要通过命令方式人工干预。

确认监视器不要和主库部署在一台机器上，避免主库网络故障时，备库无法自动切换为主库。

确认监视器不要和备库部署在一台机器上，避免主备库之间网络异常时，确认监视器误认为主库故障，将备库切换为主库，引发双主问题。

3.5 监视器命令

监视器提供以下命令来管理守护系统：

注意：

命令中参数 GROUP_NAME 和 INST_NAME 的使用说明：

对于读写分离集群和实时主备，因为监视器只允许配置一组，所以下面命令中的组名[group_name]都可以不指定；对于 MPP 主备，因为有多个组，所以需要指定组名。但是 set group 相关的命令不受此限制，如果不指定[group_name]，则所有组全部执行。

[inst_name]在有多个实例时需要指定实例名。

组名和实例名均不唯一的情况下，需要全部指定。组名和实例名用符号“.”分隔。

3.6 监视器LOG日志

监视器 LOG 日志，记录监视器自己的信息和守护进程的本地信息，在 LOG 日志中分别[monitor] 和 [ 守护进程对应的实例名 ] 开头。监视器 LOG 日志的命名格式为“dmmonitor_年月日时分秒.log”，例如“dmmonitor_20160418230523.log”。LOG日志的路径通过 dmmonitor.ini 文件中 MON_LOG_PATH 来设置。

四 守护进程

守护进程（dmwatcher）是 DM 数据守护系统不可或缺的核心部件，是数据库实例和监视器之间信息流转的桥梁。数据库实例向本地守护进程发送信息，接收本地守护进程的消息和命令；监视器（dmmonitor）接收守护进程的消息，并向守护进程发送命令；数据库实例与监视器之间没有直接的消息交互；守护进程解析并执行监视器发起的各种命令（Switchover/Takeover/Open force 等），并在必要时通知数据库实例执行相应的操作。

4.1 守护进程主要功能

守护进程是管理数据守护系统的核心部件，监视器（dmmonitor）负责发起命令，守护进程负责解析、处理命令。守护进程提供了数据库监控、故障检测、故障处理、故障恢复等各种功能。

4.1.1 监控数据库实例

守护进程负责监控数据库运行状态，必要时重启数据库服务。守护进程和实例链路建立成功后，数据库实例定时发送信息到守护进程，发送到守护进程的内容包括：实例进程 ID、实例名、数据库模式、数据库状态、FILE_LSN、CUR_LSN、MAL 链路状态、归档状态、公钥、MPP 控制文件等信息。

守护进程更新本地记录的实例信息后，同时记录该时间戳。当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息（INST_ERROR_TIME），则会认定实例故障。

如果配置了自动重启，则会将实例重启。

守护进程采用超时机制判断实例是否故障，即当前时间和上次收到消息的时间差是否超过故障认定时间（INST_ERROR_TIME），因此不建议在数据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判实例故障。

4.1.2 发送状态信息

守护进程将监控的数据库实例信息和守护进程自身的信息（包括守护类型、守护模式、守护状态、守护日志、监视器执行序列号、执行返回码等）捆绑在一起，定时发送给其他守护进程和所有监视器。

4.1.3 监控其他守护进程

接收并解析其他守护进程发送的消息，如果超过一段时间（DW_ERROR_TIME)没有收到远程守护进程消息，会将远程守护进程状态认定为ERROR 状态。另外还会结合本地数据库信息和守护进程自身状态，切换数据库的运行模式和系统状态。

守护进程采用超时机制判断远程守护进程是否故障，即当前时间和上次收到消息的时间差是否超过故障认定时间（DW_ERROR_TIME），因此不建议在数据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判远程守护进程故障。

4.1.4 接收监视器消息

主备切换、备库接管等操作都是通过监视器命令进行，监视器将操作命令分解成多个步骤顺序执行。守护进程接收这些消息并通知实例进行相应操作，例如执行 SQL 语句修改实例模式、状态、INI 参数、设置归档状态等一系列动作，这些步骤依次执行完成后，即可完成主备库的切换或备库的接管等操作。

例如，主备切换操作，监视器首先通知待切换主备库的守护进程修改状态为Switchover 状态，设置成功以后，其他监视器将不能再进行命令操作。守护进程收到监视器将实例 Mount 的命令，转发到本地实例执行，实例执行完成后返回执行结果。执行结果包含在实例向守护进程发送的消息中，守护进程根据消息中的执行码判断是否执行成功，再响应到监视器上。

监视器和守护进程之间也是采用超时机制判断对方是否故障，即当前时间和上次收到消息的时间差是否超过故障认定时间（守护进程配置的DW_ERROR_TIME），因此不建议在数据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判监视器故障。

4.1.5 主备库启动运行

数据守护系统刚启动时，所有实例处于 Mount 状态，守护进程处于 Startup 状态，启动时需要将实例转换到 Open 状态，守护进程也切换到 Open 状态，对外提供服务。

4.1.6 备库故障处理

故障自动切换模式下，备库故障后，如果主备库之间的归档状态仍然有效，主库的守护进程会先切换为 Confirm 状态，等待确认监视器的确认消息，如果确认为符合故障处理条件，主库守护进程再切换至 Failover 状态，将故障备库的归档失效。

故障手动切换模式下，备库故障后，如果主备库之间的归档状态仍然有效，会直接切换到 Failover 状态，并将故障备库的归档失效，不需要备库故障确认。

备库故障后，备库的守护进程如果还处于活动状态且监控功能没有被关闭，则会切换到Startup 状态下。备库故障重启后，如果存在活动主库，主库守护进程根据备库实例的模式、状态、备库守护进程状态、守护进程控制文件信息、以及备库的恢复间隔信息判断，是否可以进行故障恢复，在满足故障恢复条件情况下，启动 Recovery 流程，重新恢复主备库到一致状态。如果一直没有观察到主库守护进程发起Recovery 流程，可以借助监视器的 check recover 命令查找备库不满足条件的原因，并做对应的处理。

读写分离集群下，主库向即时备库发送归档失败后，会直接修改归档状态无效，并将数据库修改为 Suspend 状态。如果主备库之间出现网络故障，并且在网络故障期间，主库没有修改操作触发归档日志发送，则主库会一直保持 Open 状态。如果网络故障期间备库接管，网络恢复后，dmwatcher 会通知主库强制Halt。

4.1.7 备库异常处理

备库异常，指备库的数据库实例正常，但响应速度出现异常，这里的响应速度可能受主备库之间的网络影响，比如网络不稳定、网速大幅下降，也可能受备库自身的软硬件影响，比如操作系统原因或磁盘读写速度异常降低等异常情况导致响应回主库的速度变慢，这种情况下会极大拖慢主库性能，影响主库正常处理对外的业务请求。

守护进程提供RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度，此参数必须配置为大于 0 的值，否则守护进程不会打开监控功能。

主库守护进程在 Open 状态下对日志发送速度进行检测，一旦检测到异常，主库守护进程会切换到 Standby check 状态，并通知主库将异常备库的归档失效，暂停到此备库的数据同步，避免拖慢主库性能。

完整的备库异常处理流程如下（Standbycheck 状态处理）：

1、收集出所有的异常备库

2、通知主库修改这些异常备库的归档为 Invalid 无效状态

3、守护进程切回 Open 状态

在此状态下发现其他备库故障，且符合 failover 条件，则守护进程主动中断 Standby check 异常处理，先做 failover 故障处理。

4.1.8 主库故障处理

故障自动切换模式下，主库故障后，确认监视器会捕获到故障信息，自动选出可接管的备库，并通知备库进行接管。备库接管由确认监视器自动触发，无需用户干预。

故障手动切换模式下，主库故障后，需要人工干预，通过监视器执行接管命令，将可接管备库切换为主库。

故障自动切换模式下，可以实时处理故障，但对网络稳定性要求更高，需要确保主备库之间，主备库与守护进程之间的网络稳定可靠，否则可能会误判主库故障，备库自动接管后，出现多个 Open 状态的主库，引发脑裂。故障手动切换模式，备库不会自动接管，出现节点故障、或者网络故障时，由用户根据各种故障情况，进行人工干预。因此，我们认为故障手动切换模式，可以更好的保护数据一致性，建议尽量使用故障手动切换模式的数据守护。

主库故障重启后，守护进程根据控制文件中的接管记录，以及是否存在其他 Primary实例来判定重启后的恢复策略。可能重新作为主库加入守护系统，也可能修改为Standby 模式，以备库身份重新加入守护系统，如果出现组分裂，则需要用户干预才可以重加入守护系统。

4.1.9 故障恢复处理

故障恢复状态（Recovery）由守护进程自行判断是否切换，和监视器无关。如果符合以下条件，主库的守护进程可自动进入 Recovery 状态，进行数据恢复：

1、本地主库 [Primary,Open]，守护进程 Open 状态

2、远程备库[Standby,Open]，归档状态 Invalid，守护进程 Open 状态

3、远程备库[Standby,Open]的 clsn 和 sslsn 相等，没有待重做日志

4、控制文件判断可加入，本地 LSN 更大等

5、远程备库[Standby,Open]达到了设置的启动恢复的时间间隔

注意：

这里前 4 个条件只是概括说明，详细的条件比较多，这里不再逐一列出，如果某个备库一直没有被恢复，可以借助监视器的 check recover 命令来查找备库无法进行恢复的原因。

对于第 5 点，可通过配置主库守护进程 dmwatcher.ini 的 INST_RECOVER_TIME来控制，取值(0s~ 86400 s)，为 0 时表示满足前 4 个条件就会立即启动恢复流程，该值对所有备库有效，可通过监视器的 show archinfo 命令查看当前设置的到指定备库的恢复时间间隔。

也可以使用监视器的 setrecover time 命令来动态设置指定备库的恢复间隔，该命令只会修改命令中指定的备库的恢复间隔，并且只保存在主库的守护进程内存中，不会写入到 dmwatcher.ini 文件。

在主备库运行正常，不需要执行备库故障恢复的情况下，主库守护进程内存中对备库的恢复间隔值和 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值是一致的，在某些场景下会被设置为不同的值，下面分别进行说明：

1、主库守护进程主动修改恢复间隔为0

在以下场景中，主库的守护进程会重置内存中的INST_RECOVER_TIME 为 0，对满足前 4 个条件的备库会立即启动恢复流程：

• 数据守护系统启动完成之后。
  2) 守护系统运行过程中，主库的手动重启或者守护进程自动启动 Open 之后。
  3) 监视器执行 Switchover 主备切换/Takeover备库接管/强制 Open 主库的操作之后。

2、使用监视器命令动态修改恢复间隔

监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值：

1) set recover time [group_name.]inst_nametime_value
动态修改指定备库实例的恢复间隔，只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
2) set group [group_name] recover time time_value
动态修改指定组或所有组中所有备库的恢复间隔，只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
3) set [group_name.]para_name para_value
动态修改指定组中所有守护进程的配置参数值， para_name 允许指定为INST_RECOVER_TIME ，同时修改 dmwatcher.ini 文件和主库内存中的INST_RECOVER_TIME 值。
4) set group [group_name] para_name para_value
动态修改指定组或所有组中所有守护进程的配置参数值，para_name 允许指定为INST_RECOVER_TIME ，同时修改 dmwatcher.ini 文件和主库内存中的INST_RECOVER_TIME 值。

以上 4 个命令都可以用来修改 INST_RECOVER_TIME 值，修改完成后，一旦主库对指定备库执行过恢复操作，不管恢复执行成功或失败，通过监视器动态修改的内存值都不再有效，主库守护进程在恢复完成后，会根据恢复结果重置内存中的恢复间隔值（对dmwatcher.ini 中的值没有影响），下面分别说明如下：

1、对某个备库恢复成功，重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值

2、对某个备库恢复失败，重置此备库的恢复间隔为 1800s

1)、失败 code 等于-718，主库收集到的归档日志和待恢复备库的起始 LSN 不连续
2)、失败 code 等于-701，备库重做日志时校验 LSN 失败

待 1800s 恢复间隔之后再次满足恢复条件时，在执行恢复之前重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值，恢复完成后根据恢复结果再做判断修改。

3、对某个备库恢复失败，重置此备库的恢复间隔为 3s
失败 code 等于-722，主库发送的恢复起始 LSN 小于备库当前 SLSN，重置恢复间隔为 3s，3s 后再次尝试恢复。

4、对某个备库恢复失败，重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值

1)、失败 code 等于-721，恢复流程被守护进程或监视器命令中断
2)、失 败 code 等 于 -10050 ，待恢复备库模式或状态不匹配，不是STANDBY&OPEN 状态
3)、其他执行失败情况，重置恢复间隔为 dmwatcher.ini 中的配置值

以上这些恢复成功或失败code，以及主库对备库的恢复间隔值，都可以通过监视器的show arch info 命令查看。

完整的故障恢复流程如下：

1、同步守护控制文件，发送 dmwatcher.ctl 到备库上。

2、通知备库丢弃 KEEP_BUF。

3、通知主库发送归档日志，同步历史数据。

4、通知主库 SUSPEND。

5、再次通知主库发送归档日志。

6、主库发送 HUGE 表数据（MPP 主备）。

7、通知主库设置备库归档为 VALID 状态。

8、通知主库 OPEN

整个恢复过程中最耗时的是发送归档日志，当存在多个备库需要恢复时，为了提高恢复的效率，采用多备库并行发送归档的方式进行。守护进程每次搜集一个可恢复备库到恢复列表，按照上述故障恢复流程执行单个步骤，在等待发送归档日志的过程中，继续检测是否有备库可以恢复，如果有则加入恢复列表，也对其开始进行恢复流程处理；如果没有则检查恢复列表中是否有归档日志发送完成的备库，有则对其进行后续步骤处理，直至归档变成有效

后从恢复列表中删除。对于恢复过程中出错的备库，也从恢复列表中删除。当恢复列表为空，守护进程恢复为 OPEN 状态。

恢复过程中，守护进程会继续检测是否有恢复列表之外的备库需要恢复，如果有则可以动态加入恢复列表，实现动态并行恢复。

以下情况会导致Recovery 过程中断：

1、Recovery 过程中收到监视器的命令

2、存在多个备库时，Recovery 过程中发现其他备库故障，且符合failover 条件，则守护进程主动中断 Recovery，先做 failover 处理。

3、存在多个备库时，Recovery 过程中发现其他备库异常，则守护进程主动中断 Recovery，先做异常处理。

在守护进程打开备库异常监控的情况下，对于异常备库的恢复处理需要注意下面两点：

1、如果主备库的 LSN 已经相等，但是根据统计出来的时间信息判断主库的归档发送时间或备库的日志重演时间仍然大于设置的阀值，则不会再进入Recovery 状态，直到主库上有新的日志产生需要同步到备库，可以对统计的历史时间信息进行更新的情况下才会再进入 Recovery 状态尝试恢复。

2、在进入 Recovery 状态后，通知主库 Suspend 之前，会对主库的归档发送时间和备库的日志重演时间进行检查，在两者都小于或等于设置的阀值的情况下，才允许继续执行 Suspend，并恢复备库归档为有效状态，否则不允许再往下执行，本次 Recovery执行失败。

4.2 守护类型

守护进程支持两种守护类型：

1、本地守护

提供最基本的守护进程功能，监控本地数据库服务，如果实例使用 Mount 方式启动，守护进程会通知实例自动 Open，如果连续一段时间没有收到来自其监控数据库的消息，即认定数据库出现故障，根据配置（INST_AUTO_RESTART）确定是否使用配置的启动命令重启数据库服务。异步备库也是采用这种方式配置。

2、全局守护

实时主备、MPP 主备、和读写分离集群系统中，需要将守护进程配置为全局守护类型，守护进程根据数据库服务器配置的归档类型、以及 MPP_INI 参数情况，自动识别具体的集群类型（实时主备、MPP 主备、或者读写分离集群），全局守护类型在本地守护类型的基础上，通过和远程守护进程的交互，增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。

配置全局守护类型后，守护进程守护数据库实例，必须配置实时或即时归档，否则dmwatcher 会启动失败。

4.3 守护模式

守护进程支持 2 种故障切换模式：

1、故障自动切换

主库发生故障时，确认监视器自动选择一个备库，切换为主库对外提供服务。故障自动切换模式，要求必须且只能配置一个确认监视器。

2、故障手动切换

主库发生故障时，由用户根据实际情况，通过监视器命令将备库切换为主库。在用户干预之前，备库可以继续提供只读服务和临时表的操作。

实时主备/MPP 主备/读写分离集群都可以配置为故障自动切换或故障手动切换模式，这两种模式下守护系统的启动流程、数据同步和故障处理机制存在一定的差异，具体如下表：

一个数据守护集群，只能配置一个确认监视器。如果同时启动多个确认监视器，后启动的确认监视器将报错并自动退出。

4.4 守护状态

守护进程包括以下一些状态：

1、startup 守护进程启动状态，需要根据远程守护进程发送的状态信息，结合本地数据库的初始模式、状态和数据同步情况，确定本地数据库的启动模式和状态后，进入open 状态。2、open 守护进程正常工作，监控数据库，并定时发送数据库的状态信息，接收其他守护进程发送的信息，接收监视器发送的用户请求。

3、shutdown 守护进程停止监控数据库状态，也不提供主备库切换功能。

4、switchover 主备都正常的情况下，手动切换主备过程中设置为switchover 状态。

5、failover 远程备库故障后，本地主库执行故障处理时，守护进程设置为failover 状态。

6、recovery 故障恢复同步历史数据过程中设置为 recovery 状态。

7、confirm 通过监视器确认远程主（备）库是否活动的过程中，守护进程设置为confirm状态。

8、takeover 主库确认故障后，备库手工接管或监视器通知自动接管过程中，守护进程设置为takeover 状态。

9、open force 主库没有收到远程所有实例消息，或组中没有活动主库，需要借助监视器命令强制 open 主库或备库实例时，守护进程设置为 open force 状态。

10、error 超过一段时间（DW_ERROR_TIME）没有接收到远程守护进程消息，本地守护进程或监视器认定远程守护进程故障，修改远程守护进程为 error 状态。

11、login check 监视器执行命令登录校验时，守护进程所处的状态。

12、mppctl update 修改主库 MPP 控制文件（dmmpp.ctl）时，守护进程所处的状态，只在 MPP 主备系统出现。

13、change arch: set arch invalid 命令执行时守护进程所处的状态。

14、standby check 主库守护进程监控到备库异常后，切换到此状态下通知主库修改此备库归档无效。

守护进程所有状态变换和它监控的数据库的状态变换都会生成相应的 LOG 信息，写入到../log 目录中以’dm实例名当前年月.log’和’dmwatcher实例名当前年月.log’方式命名的日志文件中。用户可以通过查看日志文件，分析实例和守护进程的运行状态、监控故障处理过程。

守护进程的状态转换入下图所示：

从图中可以看出，守护系统主要工作在 startup 和 open 状态，几乎任何状态都可能转到这两种状态，并且这两种状态之间也可以相互转换。另外，当远程守护故障，任何状态都可转到 error 状态。

4.5 控制文件

4.5.1 概述

守护进程控制文件（dmwatcher.ctl）记录数据守护系统运行过程中守护进程组内主库变迁历史信息，是根据守护 V2.1 版本引入的一个新特性。同一个守护进程组内，所有dmwatcher.ctl 文件的内容保持一致，不同守护进程组的 dmwatcher.ctl 没有任何关联关系。Local 类型的守护进程不需要配置 dmwatcher.ctl，Global 类型的守护进程都必须配置 dmwatcher.ctl 文件。

在引入控制文件之前，为了保证主备库数据一致性，备库接管的条件十分严格，这些限制导致很多主库故障场景下使用监视器的 takeover 命令报错，只能通过一系列 SQL 进行备库强制接管。并且，用户还要记录备库接管时，主备库的LSN 信息，待故障主库恢复后，用户要根据这些信息，判断故障主库是否可以直接作为备库、重新加入数据守护系统。

引入控制文件后，守护进程根据dmwatcher.ctl 记录的信息，判断故障主库是否可以直接作为备库重新加入数据守护系统，如果故障主库的FILE_LSN > 接管备库的TAKEOVER_LSN，守护进程会将故障主库的 dmwatcher.ctl 修改为 split 状态，避免将无法保证数据一致性的库加入到数据守护系统中。

4.5.2 作用

控制文件作用如下：

1、记录数据库模式变化过程

2、判断实例是否能够加入当前主备系统

3、判断系统是否出现分裂情况

4、降低用户使用数据守护复杂度

5、提供一些更加实用、更加强大的功能特性：

1)、在无法满足自动Open 情况下，可以通过 Open Force 命令强制Open 主库。
2)、在主库故障，但备库不满足接管条件时，可以使用 Takeover Force 命令，及时恢复数据库服务。

4.5.3 内容

守护进程控制文件 dmwatcher.ctl 存放在实例的数据文件目录下。dmwatcher.ctl是由 dmwatcher.ini 文件转换生成的，使用 dmctlcvt 工具。举例如下：

./dmctlcvtTYPE=3 SRC=/dm7/data/DAMENG/dmwatcher.ini DEST=/dm7/data/DAMENG

控制文件的内容可以通过 dmctlcvt 工具转换成文本来查看，也可以通过 dmmonitor工具的 show dmwatcher ctl 命令在控制台上查看。举例如下：

dmctlcvtTYPE=4 SRC=/dm7/data/DAMENG/dmwatcher.ctl DEST=/dm7/data/DAMENG/dmwatcher.txt

守护进程控制文件 dmwatcher.ctl 维护一个全局唯一值（TGUID），每次更新控制文件，都会生成一个新的 TGUID，再加上当前旧的 TGUID 以及一些其他的描述信息，构成一个控制记录项，添加到控制文件中。文件中所有的控制记录项根据 TGUID 链接起来，可以重现守护进程组内主备库的模式、状态变化历史。

注意，守护进程控制文件 dmwatcher.ctl 最多维护100 条记录项，守护进程在添加新的记录项时会进行检查，如果超出则会自动将最老的记录项删除。

控制文件内容包括控制文件头和控制记录项。

控制文件头：

内容主要包括（记录项数目, 当前 TGUID, 控制文件状态)。

控制记录项：

控制记录项的内容包含如下信息：(TGUID 旧值，TGUID 新值，执行操作实例的 SLSN，记录生成时间，监视器 ID，操作描述信息，监视器 IP 地址)。

操作描述信息包括：Open Force、Switchover、Takeover、Takeover Force、Auto Takeover 这五种监视器操作类型，以及守护进程修改本地控制文件为INVALID 或SPLIT 状态时的描述信息。

会在控制文件中生成控制记录项的操作列举如下：

1. 监视器执行 Openinstance 命令，强制 Open 主库实例

2. 监视器执行Switchover 命令，切换主备库模式

3. 监视器执行Takeover 命令，使用备库接管故障主库

4. 监视器执行Takeover Force 命令，使用备库强制接管故障主库

5. 自动切换模式下，主库故障，确认监视器通知备库自动接管为新主库

6. 守护进程认定出现分裂或非法干预场景时，修改本地控制文件为 SPLIT 或INVALID 状态

4.5.4 状态

守护进程控制文件包含以下状态：

• 有效（VALID） 正常运行时状态。

• 无效（INVALID） 存在多个主库时设置。

• 分裂（SPLIT） 数据和有效主库的数据不一致时设置。

在某些情况下，守护进程会将控制文件状态设置为分裂或无效，设置为这两种状态后，对应的实例将不能加入守护组，需要人工干预。

无效状态产生时机：

1. 同时出现两个或两个以上的 Open 状态的主库。

2. 同时出现两个或两个以上的 SUSPEND 状态的主库。

3. 同时出现 Open 状态以及 SUSPEND 状态的主库。

4. 出现分裂的情况，重启之后，不能加入 Open 主库。
以上有些情况只会在人工非法干预下才会出现，置无效状态是为了保护数据的有效性。

分裂状态产生时机：

1. 本地实例[Primary/MOUNT]，不能加入远程实例[Primary/OPEN]。

2. 本地实例[Standby/MOUNT]，不能加入远程 Primary 实例；

3. 本地实例[Standby/OPEN]，不能加入远程 Primary 实例。

4.6 相关命令

守护进程（dmwatcher）既能以控制台方式启动，也可以配置为服务方式启动。可以在守护进程的控制台上输入命令，关闭守护进程，显示守护进程组的状态信息等，具体命令

参考下表：

守护进程版本信息说明：

守护进程版本格式为“DMWATCHER[数据守护版本号] 全局版本号”，例如：

“DMWATCHER[2.1]V7.1.5.136-Build(2016.11.24-75430)ENT”。

同一套数据守护系统中，服务器、守护进程和监视器要求中括号内的数据守护版本号必须一致，否则不允许建立 TCP 连接，各自的控制台工具上会打印版本不匹配信息。