DM7 达梦数据库数据守护(Data Watch) (3) -- 守护进程 -- cnDBA.cn

之前2篇博客了解了DM DW的基本概念和主备类型如下：
DM7 达梦数据库数据守护(Data Watch) (1) — 基本概念
https://www.cndba.cn/dave/article/3665
DM7 达梦数据库数据守护(Data Watch) (2) — 主备类型
https://www.cndba.cn/dave/article/3666

本篇继续学习DM的守护进程。

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

1 主要功能

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

1.1 监控数据库实例

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

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

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

1.2 发送状态信息

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

1.3 监控其他守护进程

　　接收并解析其他守护进程发送的消息，如果超过一段时间（DW_ERROR_TIME)没有收到远程守护进程消息，会将远程守护进程状态认定为 ERROR 状态。另外还会结合本地数据库信息和守护进程自身状态，切换数据库的运行模式和系统状态。
　　
守护进程采用超时机制判断远程守护进程是否故障，即当前时间和上次收到消息的时间差是否超过故障认定时间（DW_ERROR_TIME），因此不建议在数据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判远程守护进程故障。

1.4 接收监视器消息

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

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

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

1.5 主备库启动运行

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

1.6 备库故障处理

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

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

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

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

1.7 备库异常处理

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

　　守护进程提供 RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度，此参数必须配置为大于 0 的值，否则守护进程不会打开监控功能。
　　主库守护进程在 Open 状态下对日志发送速度进行检测，一旦检测到异常，主库守护进程会切换到 Standby check 状态，并通知主库将异常备库的归档失效，暂停到此备库的数据同步，避免拖慢主库性能。

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

收集出所有的异常备库

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

守护进程切回 Open 状态

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

1.8 主库故障处理

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

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

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

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

1.9 故障恢复处理

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

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

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

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

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

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

注意：

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

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

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

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

主库守护进程主动修改恢复间隔为 0
在以下场景中，主库的守护进程会重置内存中的 INST_RECOVER_TIME 为 0，对满足前 4 个条件的备库会立即启动恢复流程：
1) 数据守护系统启动完成之后。
2) 守护系统运行过程中，主库的手动重启或者守护进程自动启动 Open 之后。
3) 监视器执行 Switchover 主备切换/Takeover 备库接管/强制 Open 主库的操作之后。

使用监视器命令动态修改恢复间隔
监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值：
1) set recover time [group_name.]inst_name time_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 中的值没有影响），下面分别说明如下：

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

对某个备库恢复失败，重置此备库的恢复间隔为 1800s
１) 失败 code 等于-718，主库收集到的归档日志和待恢复备库的起始 LSN 不连续
２) 失败 code 等于-701，备库重做日志时校验 LSN 失败
待 1800s 恢复间隔之后再次满足恢复条件时，在执行恢复之前重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值，恢复完成后根据恢复结果再做判断修改。

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

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

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

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

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

通知备库丢弃 KEEP_BUF。

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

通知主库 SUSPEND。

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

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

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

通知主库 OPEN

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

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

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

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

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

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

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

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

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

2 守护类型

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

本地守护

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

全局守护

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

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

3 守护模式

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

故障自动切换

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

故障手动切换

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

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

比较内容	故障自动切换	故障手动切换
硬件要求	>=3 台机器	>=2 台机器
主库故障需要人工干预	否	是
备库 KEEP_BUF	有（实时主备和 MPP 主备专用）	有（实时主备和 MPP 主备专用）
需要确认监视器	是	否
支持实时主备	是	是
支持 MPP 主备	是	是
支持读写分离集群	是	是
主库故障处理	备库自动接管	备库手动接管
备库故障处理	主库可能先进入 Confirm 状态，向确认监视器求证备库故障后，再进行 Failover 处理。也可能直接 Failover 处理.	主库直接 Failover 处理
主备库切换	支持	支持

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

4 守护状态

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

startup 守护进程启动状态，需要根据远程守护进程发送的状态信息，结合本地数据库的初始模式、状态和数据同步情况，确定本地数据库的启动模式和状态后，进入open 状态。 
open 守护进程正常工作，监控数据库，并定时发送数据库的状态信息，接收其他守护进程发送的信息，接收监视器发送的用户请求。
shutdown 守护进程停止监控数据库状态，也不提供主备库切换功能。
switchover 主备都正常的情况下，手动切换主备过程中设置为switchover 状态。
failover 远程备库故障后，本地主库执行故障处理时，守护进程设置为 failover 状态。
recovery 故障恢复同步历史数据过程中设置为 recovery 状态。
confirm 通过监视器确认远程主（备）库是否活动的过程中，守护进程设置为confirm 状态。
takeover 主库确认故障后，备库手工接管或监视器通知自动接管过程中，守护进程设置为 takeover 状态。
open force 主库没有收到远程所有实例消息，或组中没有活动主库，需要借助监视器命令强制 open 主库或备库实例时，守护进程设置为 open force 状态。
error 超过一段时间（DW_ERROR_TIME）没有接收到远程守护进程消息，本地守护进程或监视器认定远程守护进程故障，修改远程守护进程为 error 状态。
login check 监视器执行命令登录校验时，守护进程所处的状态。
mppctl update 修改主库 MPP 控制文件（dmmpp.ctl）时，守护进程所处的状态，只在 MPP 主备系统出现。
change arch: set arch invalid 命令执行时守护进程所处的状态。
standby check 主库守护进程监控到备库异常后，切换到此状态下通知主库修改此备库归档无效。

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

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

5 控制文件

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 状态，避免将无法保证数据一致性的库加入到数据守护系统中。

5.2 作用

控制文件作用如下：

记录数据库模式变化过程

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

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

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

提供一些更加实用、更加强大的功能特性：
1) 在无法满足自动 Open 情况下，可以通过 Open Force 命令强制 Open 主库。
2) 在主库故障，但备库不满足接管条件时，可以使用 Takeover Force 命令，及时恢复数据库服务。

5.3 内容

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

./dmctlcvt TYPE=3 SRC=/dm7/data/DAMENG/dmwatcher.ini DEST=/dm7/data/DAMENG

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

dmctlcvt TYPE=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 状态时的描述信息。

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

监视器执行 Open instance 命令，强制 Open 主库实例

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

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

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

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

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

5.4 状态

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

 有效（VALID）正常运行时状态。
 无效（INVALID）存在多个主库时设置。
 分裂（SPLIT）数据和有效主库的数据不一致时设置。

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

无效状态产生时机：

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

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

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

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

分裂状态产生时机：

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

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

6 相关命令

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

命令	含义
HELP	帮助
EXIT	退出守护进程
STATUS	显示守护进程运行状态
SHOW	显示所有组的守护进程及其监控数据库的状态信息
SHOW GROUP GROUP_NAME	显示指定组的守护进程和监控数据库的状态信息
SHOW VERSION	显示守护进程自身版本信息
SHOW MONITOR CONFIG	帮助监视器配置 ini 文件的信息

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

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

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

签到成功

CNDBA社区