本文主要针对达梦数据库管理系统的数据守护集群（DM8 Data Watch）进行研究探索，目的在于使读者快速理解数据守护集群的基本原理和基本运维监控方法。熟悉甲骨文数据库Data Guard技术原理的读者阅读本文将更有更多的收获。

一、基础架构研究
达梦数据库的数据守护集群就是一种主备模式的高可用架构：即主库加备库模式，主备库之间存在数据同步。一旦主库发生灾难，由备库承接应用。
下图是达梦数据守护架构图。

数据守护的核心组件是dmwatcher守护进程和dmmonitor监视器。数据同步依赖与于达梦特有的MAL系统。MAL 系统是基于 TCP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。达梦通过 MAL 系统实现 Redo 日志传输，以及其他一些实例间的消息通讯。在物理组成上，MAL系统需要在数据库服务器上单独规划一片网卡，并使之与业务网络隔离。
下图是甲骨文11g数据库Data Guard架构。甲骨文数据同步依赖于普通的业务网络，数据的发送和接收主要依赖LGWR、NSS或NSA、ARCn、RFS和MRP等进程。

达梦数据守护（Data Watch）是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。通过部署达梦数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下，避免数据损坏、丢失，保障数据安全，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。与常规的数据库备份还原技术相比，数据守护可以更快地恢复数据库服务。随着数据规模不断增长，通过还原手段恢复数据，往往需要数个小时、甚至更长时间，而数据守护基本不受数据规模的影响，只需数秒时间就可以将备库切换为主库对外提供数据库服务。
达梦数据守护可以实现基础的实时主备，并可以实现读写分离集群、大规模并行处理集群主备。
实时主备由一个主库以及一个或者多个配置了实时（Realtime）归档的备库组成，其主要目的是保障数据库可用性，提高数据安全性。实时主备系统中，主库提供完整的数据库功能，备库提供只读服务。主库修改数据产生的Redo日志，通过实时归档机制，在写入联机Redo日志文件之前发送到备库，实时备库通过重演Redo日志与主库保持数据同步。当主库出现故障时，备库在将所有Redo日志重演结束后，就可以切换为主库对外提供数据库服务。
主备架构下数据的同步最终依赖于数据库的Redo 日志传输。
主备库之间的 Redo 日志传输，以日志包 RLOG_PKG 为单位，主库通过 MAL 系统发送Redo 日志到备库。各种不同数据守护类型的区别，就在于主库日志包 RLOG_PKG 的发送时机，以及备库收到 Redo 日志后的处理策略。RLOG_PKG 具有自描述、自校验特征，数据的组织形式更加灵活、高效。
守护进程（dmwatcher）是达梦数据守护系统不可或缺的核心部件，是数据库实例和监视器之间信息流转的桥梁。数据库实例向本地守护进程发送信息，接收本地守护进程的消息和命令；监视器（dmmonitor）接收守护进程的消息，并向守护进程发送命令；数据库实例与监视器之间没有直接的消息交互；守护进程解析并执行监视器发起的各种命令（Switchover/Takeover/Open database 等），并在必要时通知数据库实例执行相应的操作。
监视器（dmmonitor）用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。如果没有第三台机器，也可以部署到备库所在的服务器上。
通过监视器，可以监控数据守护系统的运行情况，获取主备库状态、守护进程状态以及主备库数据同步情况等信息。同时，监视器（dmmonitor）还提供了一系列命令来管理数据守护系统。监视器的基本作用是：监控、管理数据守护系统，确认状态信息，发起故障自动接管命令。
监视器支持两种运行模式：监控模式和确认模式。监视器运行模式由配置文件（dmmonitor.ini）的 MON_DW_CONFIRM 参数来确定。MON_DW_CONFIRM 参数的默认值是 0，表示监控模式；MON_DW_CONFIRM 参数值为 1 时，表示监视器运行在确认模式下。
在生产环境中的最佳实践是把MON_DW_CONFIRM参数设置为0，使监视器处于监控模式，避免一些不可控的因素让监视器“自作主张”地干预主备库的运行从而造成生产系统的不确定性。

二、归档模式研究
归档日志是关系数据库的重要概念。达梦数据守护的归档模式对高可用架构的性能与数据安全至关重要。下面引入达梦两个概念：实时归档和及时归档。
实时归档与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的Redo 日志通过 MAL 系统传递到备库，实时归档是实时主备的实现基础。实时归档只在主库生效。
实时归档的执行流程是，主库在 Redo 日志（RLOG_PKG）写入联机日志文件前，将 Redo日志发送到备库，备库收到 Redo 日志（RLOG_PKG）后标记为 KEEP_PKG，将原 KEEP_PKG加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。主库收到备库的响应消息，确认备库已经收到 Redo 日志后，再将 Redo 日志写入联机日志文件中。
即时归档（Timely）在主库将 Redo 日志写入联机日志文件后，通过 MAL 系统将 Redo日志发送到备库。即时归档与实时归档的主要区别是 Redo 日志的发送时机不同。
根据备库重演 Redo 日志和响应主库时机的不同，即时归档分为两种模式：事务一致模式和高性能模式。即时归档模式根据配置文件 dmarch.ini 中的 ARCH_WAIT_APPLY 配置项（默认值为 1）来确定，1 表示事务一致模式，0 表示高性能模式。
事务一致模式：主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志，并重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，
查询结果都满足 READ COMMIT 隔离级要求。这种模式非常类似于甲骨文Data Guard的Maximum Protection模式。
高性能模式：与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。这种模式非常类似于甲骨文Data Guard的Maximum Performance模式。
事务一致模式下，主备库之间严格维护事务一致性，但主库要等备库 Redo 日志重演完成后，再响应用户的提交请求，事务提交时间会变长，存在一定的性能损失。高性能模式则通过牺牲事务一致性获得更高的性能和提升系统的吞吐量。

三、DMDSC架构下的数据守护
达梦支持 DMDSC 和 DMDSC、DMDSC 和单节点、单节点和 DMDSC 之间互为主备的数据守护。
数据守护以库为单位进行管理，一个 DMDSC 集群的所有实例作为一个整体库来考虑。DMDSC 集群的库信息，例如库的状态、模式等需要综合考虑集群内所有实例，同时需要结合 DMDSC 本身的状态。
总体原则说明：
DMDSC集群各个节点分别部署守护进程（dmwatcher）。
DMDSC集群数据库控制节点的守护进程，称为控制守护进程，普通节点的守护进程称为普通守护进程，如果控制节点发生变化，则控制守护进程也相应变化。守护进程会连接DMDSC集群所有实例，但只有控制守护进程会发起OPEN、故障处理、故障恢复等各种命令。普通守护进程不处理用户命令，但接收其他库的控制守护进程消息。
主备实时同步数据时，DMDSC集群主库各个节点将各自产生的联机日志发送到备库控制节点（重演节点）进行重演，备库普通节点不接收日志。控制守护进程定时发送消息给其他库的守护进程以及监视器，普通守护进程只发送给监视器，不会发送给其他库的守护进程。
DMDSC集群内部不同实例的守护进程之间不通信。
普通守护进程连接DMDSC中所有实例，但只记录每个实例的信息，不做任何操作。同一个DMDSC集群内的所有守护进程之间不进行连接。
DMDSC中每个实例存在多个守护进程的连接，向每个dmwatcher发送广播消息，但只可能接收控制守护进程的命令。
不同库之间的守护进程都建立连接。
守护进程和dmcss建立连接，部分监视器执行命令通过守护进程转发，由dmcss执行。

归档配置
1.DMDSC集群必须配置远程归档，用于DMDSC节点故障后的数据同步。
2.如果归档目标是DMDSC集群，则归档的目标节点需要同时配置DMDSC集群所有实例，一个DMDSC集群作为一个整体进行配置。
下图的数据守护架构中，主库是DMDSC集群，备库是单节点。

四、数据守护的运维监控
对于最终用户而言，更需要掌握的是数据守护的运维监控。达梦数据守护运维有其天然的便利性——dmmonitor工具。
达梦数据库管理系统的运维监控工具的运行方式通常为“工具的二进制可执行文件”+“本工具的运行配置文件”语法格式，举例如下：
./dmmonitor /绝对路径/dmmonitor.ini
其中dmmonitor是二进制可执行文件，dmmonitor.ini是配置文件。执行情况如下图，进入dmmonitor工具后，执行show命令，即可监控全局的数据守护集群状态：
关键监控字段释义如下：
1.组全局字段信息
OGUID：
数据守护唯一标识码，配置数据守护时，需要由用户指定 OGUID 值。其中数据库的OGUID 在 MOUNT 状态下由系统函数 SP_SET_OGUID 设置，守护进程和监视器的 OGUID 值在配置文件中设定。同一守护进程组中的所有数据库、守护进程和监视器，都必须配置相同的 OGUID 值，取值范围为 0~2147483647。
GROUP：
守护进程组名。
MON_CONFIRM：（最佳实践是false）
监视器是否配置为确认模式，值为 TRUE 或 FALSE。
2.库全局字段信息
DW_IP：
守护进程的 IP 地址，取自控制守护进程。
MAL_DW_PORT：
守护进程的监听端口，取自控制守护进程。
WTIME：
守护进程本地的当前时间，取自控制守护进程。
WTYPE：（通常为global）
守护进程配置的守护类型，包括 LOCAL/GLOBAL 两种类型，取自控制守护进程。通常案例中均使用global类型。对于local类型的守护进程配置，笔者研究尚未开展研究。
WCTLSTAT：（通常为valid）
守护进程控制文件状态，包括 Valid/Split/Invalid 三种状态，对于配置为本地守护类型的实例，由于不需要有守护进程控制文件，该字段值为 NULL。只有当数据守护发生故障时，才会产生控制文件。
WSTATUS：（正常为open）
守护进程状态，取自控制守护进程。
INAME：
库名称，取自控制节点实例名。
N_EP：
库的节点个数，比如DMDSC集群内有两个节点，那么N_EP=2。
MODE：（通常为manual）
切换模式，AUTO 表示故障自动切换模式，MANUAL 表示故障手动切换模式
N_OK：（正常等于n_ep的值）
DMDSC 集群内 OK 节点个数。
INST_OK：
守护进程认定的节点实例状态，Ok 或 Error。
ISTATUS：（正常为OK）
数据库状态，包括 Startup/After Redo/Mount/Open/Suspend/Shutdown 这几种状态，由控制守护进程综合当前所有节点实例的状态得出。
IMODE：（正常情况下主库实例为primary，备库实例为standby）
数据库模式，包括 Unknown/Normal/Primary/Standby 这四种模式，由控制守护进程综合当前所有节点实例的模式得出。
RTYPE：（通常为timely）
数据库配置的归档类型，只统计 REALTIME/TIMELY 这两种归档类型，如果这两种归档都没有配置，则显示为 NONE。
RSTAT ： （正常为valid）
此 字 段 对 备 库 有 效 ， 表 示 主 库 到 备 库 的 归 档 状 态 ， 可 能 为Valid/Invalid/Unknown。对于主库本身，此字段值为 Valid。该字段值要从备库对应的主库实例上取，如果当前没有活动主库或者备库无法确认对应的主库，则该字段显示为 Unknown。
DSC_STATUS：（正常为dsc_open）
此字段对单节点可忽略，只对 DMDSC 集群内的节点有意义，表示节点当前的 DMDSC 集群状态。
DSC_CTL_NODE：（正常为0）
DSC集群控制节点是在哪个实例上，一般而言控制节点要求在DSC_SEQNO最小的实例上才能保证switchover。

五、主备库应急切换宝典
数据守护集群存在的终极目的就在于主库发生灾难时，能应急切换到备库。所以最终用户一定要把切换脚本准备好！下面是干货。
第一步：进入dmmonitor监视器
./dmmonitor /绝对路径/dmmonitor.ini
第二步：输入show命令查看数据守护全局状态
show
第三步：输入login登录命令
login
第四步：输入sysdba用户名和密码
username:sysdba
password:xxxxx
第五步：输入终极切换命令，等待备库切换为主库。
takeover force

六、总结
达梦Data Watch和甲骨文Data Guard，从产品名称上就很类似，充分体现了达梦数据库管理系统的针对性。本文研究了Data Watch的基础架构和常用的运维监控方法，对认识和研究达梦数据库主备高可用架构起到抛砖引玉的作用。
二者除了原理层的不同特性之外，还有以下直观的区别：
1.搭建条件：
同样开启归档的情况下，甲骨文搭建备库不需要重启主库，应用无需停机，对应用影响极小；达梦搭建备库由于各项参数的限制等因素，需要重启主库，需要有业务的停机时间。达梦没有类似甲骨文的rman duplicate机制，也是其必须停库的重要原因。
2.网络需求不同
甲骨文数据库直接使用业务网络和后台进程进行数据同步；达梦需要使用专业的MAL系统同步数据。换言之，针对达梦数据库服务器，搭建备库需要单独规划一张MAL系统的专用网卡。
3.备库功能
甲骨文Data Guard物理备库可以转化为快照库模式，使备库成为read write，给应用输出测试库资源，测试完毕后再转化回备库read only模式提供高可用。甲骨文Data Guard还有逻辑备库模式。
4.监视器
与达梦类似，甲骨文也有专用的Data Guard的监控工具——“Broker”。但Broker的并不像dmmonitor那样成为必要组件，Data Guard的主备库切换、快照库转化都可以直接在sqlplus执行，没有Broker也可执行。反观Data Watch的dmmonitor使必须存在的，因为它继承了所有的监控和灾备切换职责。
以上几点小小的不同，管中窥豹地反映出达梦数据库DataWatch的特点。作为国产数据库中翘楚，达梦必将行稳致远。