自治集群归档简介

DM9 自治容灾集群基于 Raft 一致性协议设计，采用奇数副本制和 XMAL 通信机制，构建了一套高可用、强一致性的数据库存储解决方案。
自治主要体现在这：选主、日志同步、故障自愈全部由 RAFT 协议在数据库内核内完成，运维组件不需要了。
容灾模式有两种，第一为raft归档，第二为 Learner 归档。
raft归档：
Raft 归档是达梦自治容灾集群功能实现的核心基础，主库通过 XMAL 通信机制将 REDO 日志传递至备库。
Raft 归档仅在主库中生效，单个主库可配置 2 至 8 个 Raft 备库，且归档 目标的数量必须为偶数，以确保整体实例数量保持为奇数。
Learner 归档：
在达梦自治容灾集群搭建完毕之后，若需动态新增副本，将采用 Learner 归档机制进行 处理。
新副本首先以 Learner 归档模式加入集群，成为 Learner 副本，待其与主库数据同步 一致后，可以选择继续作为 Learner 副本在集群中运行，相当于只读备库，不参与主库选举 和日志提交；也可以选择转变为 Raft 归档模式，成为 Raft 副本，参与主库选举和日志提交。
Learner 副本支持动态转换为 Raft 副本，无需重启集群内的原有副本。

raft核心机制一：

日志复制（写前发、异步等、多数派提交）
这是 RAFT 归档最容易被误解的地方，它其实是发送不阻塞、提交看多数派两段式：

1. 发送阶段（不等待响应）
   主库在 REDO 日志包 RLOG_PKG 写入本地联机日志文件之前，就通过 XMAL 把它发给所有备库，不等待备库回应就继续往下执行。这一点和 REALTIME 归档"发完还要等 ACK 才继续"有本质区别，主库写入路径极短。
2. 确认阶段（备库刷盘后回报）
   备库收到日志包后：加入本地日志重演任务队列 → 日志包写入本地日志文件 → 回送一条刷盘消息给主库，携带自身的 F_SEQNO（已刷盘日志包序号）和 F_LSN（对应最大 LSN）。
3. 提交阶段（多数派推进）
   主库维护一张各副本提交进度表 F_SEQ_ARR / F_LSN_ARR，专用线程监控：
   F_SEQ_ARR = [200, 100, 100] // 主库自己 + 1 个备库刷盘
   F_SEQ_ARR = [200, 200, 100] // 第 2 个副本刷盘 → 达到多数派 Q=2
   → C_SEQNO : 100 → 200 // 主库提交，推进提交位点

超过半数节点（含主库自身）刷盘后，主库把该日志包的序号和 LSN 置为 C_SEQNO / C_LSN（已提交日志包序号 / 已提交包中最大 LSN）。主库再通过下一个日志包或心跳消息把新的 C_SEQNO/C_LSN 带给备库，备库据此推进自己的提交位点。

raft核心机制二：

选举与任期
多数派规则：Q = floor(N/2) + 1。N=3 时 Q=2，因此三副本最多容忍 1 个节点失效；5 副本容忍 2 个。副本总数 N 必须是奇数，支持 3/5/7/9 规格。
心跳维持：Leader 按 RAFT_HB_INTERVAL 周期性广播心跳维持任期权威。
超时发起选举：Follower 超过 RAFT_VOTE_INTERVAL 没收到有效心跳 → 任期号 +1 → 转 Candidate → 拉票；获多数票即成为新 Leader。
脑裂规避：任期（Term）单调递增，旧 Leader 收到更高 Term 的消息会退回 Follower。
差异化超时：三个节点 RAFT_VOTE_INTERVAL 必须配成不同值（如 3000/5000/7000 ms），值越小优先级越高，避免同时发起选举导致选票瓜分
归档区别图片：

总结：
AFC自治容灾集群（raft归档）解决了，跨数据中心的集群快速切换问题。
减少了跨数据中心的网络延迟对数据库的影响。
备注：
datawatch数据守护（实时归档）解决了，同一数据中心集群快速切换问题。
datawatch数据守护（同步归档、即时归档）不能快速自动切换，需要人员介入进行恢复数据库。
因此：体现了自治容灾集群的优点，具有一定的可选择性。
自治容灾集群跨数据中心，建设建议采用两地三中心的方法进行部署。