达梦DW与AFC对比

对比达梦的两款高可用集群：

数据守护集群（Data Watch，DW）与自治容灾集群（Autonomous Failover Cluster，AFC）

一、背景

达梦数据库（DM）在 DM9 系列中同时提供了两款面向高可用的集群产品：

产品	英文全称	协议/模型	对标
数据守护集群	Data Watch（DW）	中心化主备 + 监视器仲裁	Oracle Data Guard
自治容灾集群	Autonomous Failover Cluster（AFC）	去中心化 Raft 多数派	MySQL 组复制 / TiDB Raft

同一个厂商、同一个数据库内核，为什么要同时维护两套高可用方案？二者是不是新旧替代关系？本文基于官方手册《DM9-数据守护与读写分离集群》与《DM9-自治容灾集群》，从架构、技术路线、关键机制、优劣与适用场景几个维度做拆解，帮助读者建立选型框架。

先说结论：AFC 不是 DW 的替代品，二者是技术路线不同的并行产品线。 它们在达梦统一的 Redo 日志 + 数据页 + 内部通信（MAL/XMAL）底座的之上，走出了两条不同的高可用路。

二、DataWatch：中心化主备架构

2.1 架构模型

DW 的实现原理：主库产生 Redo 日志，通过 MAL 系统以日志包（RLOG_PKG）为单位传输到备库，备库重演日志保持数据同步。系统由五个组件组成：

组件	说明
主库（Primary）	提供完整数据库服务，写请求的唯一入口
备库（Standby）	只读服务 + 容灾，重演 Redo 日志
Redo/RLOG_PKG	同步载体，每个日志包有递增的包序号（PKG SEQNO）
守护进程 `dmwatcher`	每机一个，监控实例状态与同步情况，消息中转
监视器 `dmmonitor`	独立部署，执行命令、实现自动切换

复制代码

┌──────────┐   RLOG_PKG（MAL）    ┌──────────┐
│  主库    │  ─────────────────▶ │  备库 ×N  │
│  Primary │ ◀─────────────────  │  Standby │
└──────────┘     日志重演         └──────────┘
      │                                │
      ▼  status/cmd                    ▼
┌──────────────┐                 ┌──────────────┐
│ 守护进程      │ ◀──────────▶  │  监视器       │
│  dmwatcher   │                 │  dmmonitor   │
└──────────────┘                 └──────────────┘

其中监视器又分普通监视器 与确认监视器 。关键点：只有运行在确认模式下的监视器才能实现自动故障切换，且官方要求确认监视器部署在独立第三方机器上（避免与某数据库实例同机，防止网络分区时误切换引发脑裂）。

2.2 技术路线：一产品多形态

DW 的定位是"集成化高可用解决方案"，同一套机制可配置成四种集群：

实时主备：主库 + 实时（Realtime）归档备库，目标是最小化数据丢失；
MPP 主备：为 MPP 集群每个节点各配一套主备，每个主备称为一个"守护进程组（Group）"；
DMDSC 主备：DMDSC 共享存储集群与单节点、或 DSC 集群之间互为主备；
读写分离集群：主库 + 即时（Timely）/实时归档备库，接口层自动读写分流。

2.3 关键参数与配置

DW 涉及的配置文件比 AFC 多，这也是其运维复杂度的直接来源：

文件	作用
`dm.ini`	实例参数，如 `ALTER_MODE_STATUS`（防误改模式状态）
`dmmal.ini`	MAL 系统配置，实例间通信地址
`dmarch.ini`	归档配置，声明实时/即时/异步等归档目标
`dmwatcher.ini`	守护进程配置
`dmmonitor.ini`	监视器配置
`dmtimer.ini`	定时器（异步归档用）

日志同步时机由归档类型决定，dmarch.ini 中的 ARCH_WAIT_APPLY（或 WAIT_APPLY）控制即时归档是否等待备库重演完成：

事务一致模式 （ARCH_WAIT_APPLY=1，即时归档默认）：主库等备库重演完成才响应用户提交；
高性能模式 （ARCH_WAIT_APPLY=0，实时归档默认）：备库收到即应答，主备存在一定延时。

2.4 优势

功能覆盖最全：实时主备、MPP 主备、DSC 主备、读写分离四种形态，加异步/同步/订阅/级联备库，传统主备组合基本全覆盖。
读写分离为独有能力 ：通过 JDBC/DPI 接口 + dm_svc.conf 中的 RW_SEPARATE/RW_PERCENT 配置，把只读事务按比例分流到备库，这是 AFC 不具备的。
一致性分级可选：五档备库类型，从强一致到冷备可按需选择，性能与安全可调。
生态成熟度高：手册 832 页，故障场景覆盖到组分裂、脑裂、归档修复、数据页损坏修复，可参考的运维案例丰富。

2.5 劣势与限制

防脑裂依赖确认监视器（单点风险）：自动切换强依赖确认监视器，监视器自身故障则自动切换失效。
运维重：组件与配置文件多，排障链路长。
强一致非协议级保证：实时归档下"备库确认收到 ≠ 已完成重演"，高性能模式更显式允许延迟，真正的零丢失需配合同步备库等特定部署。
强同步下的牵制效应：实时归档要求主库在写联机日志前先送达备库；备库故障/网络异常时，主库会"试图切换 Suspend 状态"自保，写操作将被挂起。
脑裂/组分裂需人工规避：手册将脑裂成因归结为"网络不稳 + 人工误操作"，并要求用户通过配置与操作纪律来降低风险。

三、AFC：基于 Raft 的自治容灾集群

3.1 架构模型

AFC 基于 Raft 一致性协议 ，采用奇数副本制（N=3/5/7/9）与 XMAL 通信机制，核心思路是让副本通过投票自治选举，去掉外部仲裁组件。副本分为四种角色：

角色	说明
Leader（领导者）	唯一处理写请求，定时发心跳与日志
Follower（跟随者）	接收并重演日志，参与选举
Candidate（候选者）	Follower 发起选举时的临时角色
Learner（学习者）	只重演日志，不参与选举与提交

复制代码

        ┌─────────────── 三副本 AFC 集群 ───────────────┐
        │                                              │
    ┌────────┐  XMAL 心跳 + REDO 日志     ┌────────┐    │
    │ Leader │ ◀──────────────────────▶ │Follower│    │
    │ 主库   │                           │  备库   │    │
    └────────┘                           └────────┘     │
        │  ▲                               │  ▲         │
        └──┼───────────────────────────────┘  │         │
           └──── 写入多数副本（过半）即提交 ────┘         │
                                        ┌────────┐      │
                                        │Follower│      │
                                        │  备库   │     │
                                        └────────┘      │
                                     Learner 副本（只读，可选）

3.2 技术路线：协议级强一致 + 自治

Raft 自动选主 ：备库在 RAFT_VOTE_INTERVAL 内收不到 Leader 心跳即发起选举，任期号 +1，过半投票当选；心跳间隔由 RAFT_HB_INTERVAL 控制。
多数派日志提交 ：日志写入多数副本（含主库）的联机日志文件后即提交，主库推进 COMMIT_SEQ（C_SEQ）与 COMMIT_LSN（C_LSN）；
Raft 归档 / Learner 归档：主库通过 Raft 归档向 Raft 备库异步发日志（无需等待响应），动态扩缩容时新副本以 Learner 归档模式加入、追平后转 Raft；
影子副本：只写联机日志与归档、不重演（不生成数据文件），参与选举与提交，用于降低存储成本；
原生两地三中心 / 三地三中心：跨地域强一致容灾，五副本（2+2+1）架构下异地中心不参与提交。

3.3 关键参数与视图

项	说明
`RAFT_VOTE_INTERVAL`	选举超时间隔，建议各副本配不同值以降低"选票瓜分"概率
`RAFT_HB_INTERVAL`	Leader 心跳间隔
`RAFT_HP_TIMEOUT`	日志堆积判定超时，超时未推进则主库转只读
`SHADOW_CHECK_INTERVAL`	影子副本归档清理间隔
系统过程	`SP_SET_RAFT_ELECT`、`SP_ADD_RAFT_LEARNER`、`SP_SINGLE_TO_RAFT` 等
视图	`V$RLOG_RAFT_INFO`（`RAFT_SHADOW` 字段判断是否影子副本、`HP_FLAG` 判断堆积）、`V$ARCH_STATUS`（归档状态）、`V$GLOBAL_RAFT_INFO`

3.4 优势

协议级强一致、真零丢失：政务/金融场景要的"提交即持久化"由 Raft 协议直接保证，不依赖部署配置。
自动选主、无外部仲裁：无监视器、无守护进程，副本自治选举，天然防脑裂。
容错能力可计算 ：奇数副本可靠容忍 (N-1)/2 个副本故障；5 副本两地三中心下异地不参与提交、不拖慢事务。
在线弹性伸缩：Learner 机制支持不停机增删副本。
降本手段：影子副本以极小存储扩展"投票权"。
故障韧性：多数副本故障时主库自动降级只读（HP_FLAG 机制），而非硬卡死。

3.5 劣势与限制

多数副本故障即整体不可写：Raft 天然代价，故障过半无法提交，只能等多数副本恢复或走强制缩容。
无读写分离：Learner/备库只提供只读，缺 DW 的接口级自动分流。
跨地域强一致有延迟代价：提交需等多数副本写盘。（这一点没有做过实际性能测试，不清楚具体有多大影响。但看起来理论上数据同步是会比DW延迟更高的。raft协议是异步同步日志但多数派确认提交，意思是，『提交点』必须等多数副本写盘确认后才推进，因此事务的提交延迟（而非写入延迟）天然受多数副本、尤其是异地副本的网络 RTT 约束。相比之下，DW是可以配置成异步备库，不会为了一致性而牺牲主库响应性能。这一点应该是DW和AFC在设计初衷上最本质的差异，两者在一致性和实时响应能力这两方面，做了不同的取舍，对应不同的场景需求）
起步成本高：奇数副本至少 3 份完整数据。（如果设置成影子副本可以至少2份数据，就是影子副本是不能超过节点半数的，一共2n+1个节点，最多n个影子副本，所以最少存n+1份完整数据）
协议概念有学习门槛：日志截断、任期号、主动 Halt（强制退出回滚数据页）对传统 DBA 是新概念。
产品较新：手册 164 页，故障预案与周边生态积累弱于 DW。
硬性约束：Raft 副本必须奇数（3~9）；影子副本数量 ≤ 副本总数一半，且不支持动态增删、升级降级仅能重建。

四、核心机制原理对比

4.1 一致性模型

维度	DW	AFC
一致性来源	归档类型配置	Raft 协议
提交判定	备库"确认接收"（实时）或"重演完成"（事务一致）	写入多数副本
弱一致能力	高性能模式 / 异步 / 订阅备库	无（Learner 只读但不降低主库一致性）
脑裂防护	确认监视器仲裁	任期号 + 多数派，天然无脑裂

4.2 故障切换

场景	DW	AFC
主库故障	确认监视器选备库接管（自动）或 `Takeover` 命令（手动）	备库超时触发选举，自动选出新 Leader
备库故障	归档置 Invalid，恢复后自动重同步	归档置 Invalid，恢复后异步重加入
切换时间	受监视器检测与命令链路影响	单次选举超时 + 投票（秒级量级）
切换前数据风险	实时/高性能模式存在未重演窗口	多数派提交，无未提交丢失

4.3 一致性隐患

DW 最需要注意的是实时归档的 Suspend 自保机制 ：主库在备库不可达时切入 Suspend、挂起写操作，换取主备一致性。AFC 则相反------多数派提交决定了少数备库故障完全不影响主库写，这是二者在"故障容忍"上最本质的差异。

五、横向对比与选型

维度	DW	AFC
架构范式	中心化主备	去中心化 Raft
最小部署	1 主 + 1 备 + 监视器	3 副本
仲裁组件	dmwatcher + dmmonitor（必要）	无
自动切换	支持（依赖确认监视器）	支持（自治）
读写分离	支持	不支持
MPP / DSC 组合	支持	不支持
强一致	分级配置	协议保证
最低容灾冗余	1 主 + 1 可用备即可续命（如果是异步/即时归档模式，实际上备库全宕机了只剩1个主库也可以继续提供服务，只不过就是没有容灾能力的单机。如果是实时归档模式，备库全宕机后，主库会进入 Suspend 自保、挂起写操作）	需多数副本存活（如果超过半数节点宕机，整个系统就不能正常提供服务了，文档里面说的是"只能读不能写"，可以理解为"数据库级只读限制"『能 SELECT、能查，但禁写』，既不是"只能查系统视图"，也不是 DW 那种接口层自动分流到备库的读写分离。
运维复杂度	高	中
存储成本	低（2 份起）	高（3 份起）
成熟度	高	较新

选型建议：

需要读写分离、负载均衡、MPP/DSC 组合、可容忍备库延迟 → 选 DW。
需要金融级强一致零丢失、跨地域自动容灾、去仲裁组件简化运维 → 选 AFC。
二者可组合：本地用 DSC/DW 做读写与高可用，异地用 AFC 拉强一致副本链。（不是指在一套系统里面集成2个产品的意思，AFC只能自己单独搞，不能和其他产品集成）所谓"组合"是指在同一套业务/数据中心里分层部署（如本地用 DSC/DW 做高可用，异地独立部署一套 AFC 做强一致容灾），二者在数据链路/信道层面配合，而不是"一个集群内相互集成"。

六、总结

DW 与 AFC 是达梦在"高可用"这一目标下，走出的两条不同技术路线：

DW 延续了经典主备的成熟范式（中心节点 + 监视器仲裁），优势是功能全、读写分离、生态成熟 ，代价是组件多、防脑裂依赖监视器单点；
AFC 引入了分布式共识协议（Raft 多数派 + 自治选举），优势是强一致、自动选主、架构简约 ，代价是容灾冗余门槛高、无读写分离、产品尚新。

二者共享达梦的统一数据库底座------AFC 手册中大量基础概念（数据库模式/状态、LSN、Redo、归档）直接引用自 DW 手册，也从侧面印证了这不是"替代"而是"同底座的不同分支"。

落地的选择标准不应该是"谁更新"，而应该是业务诉求：

求弹性与读写分流，选 DW；求强一致与自治容灾，选 AFC。

参考资料：《DM9-数据守护与读写分离集群》《DM9-自治容灾集群》（达梦官方手册）。