GaussDB Kernel V5 集群管理层关键模块如下。
图4 集群管理层组件设计图
CM 组件提供了四种服务 CM Agent, CM Server, OM Monitor, cm_ctl，与各类实例服务组件（CN, DN, GTM 等）一起构成了整个数据库集群系统。
cm_ctl
通过命令行执行集群的启动、停止、状态查询、主备倒换、备机重建等功能
除启动和停止外，主要通过与 CM Server 的消息传递执行命令
可在任意节点执行并获取到相同的结果
OM Monitor
由系统定时任务拉起
负责 CM Agent 的运行状态监控
CM Agent
由 OM Monitor 拉起
负责拉起和停止所在节点的 CN, DN, GTM, CM Server（如果存在）；监控实例状态并上报至 CM Server；执行 CM Server 下发的命令等
对应 cm_agent 二进制文件，所有节点常驻服务
CM Server
由 CM Agent 拉起，是整个集群管理组件的大脑
负责接收 cm_ctl 发送的命令并下发至 CM Agent；接收并处理 CM Agent 上报的实例状态，下发仲裁指令保证各类故障和异常场景下集群的可用性
对应 cm_server 二进制文件，常驻服务
CM与各类组件的主备数据同步、倒换、重建等机制高度融合，提供告警、重启、倒换、隔离等手段，赋予数据库实例故障恢复及自愈的高可用（HA）能力，保证数据的可靠性和完整性，最终实现集群对外的业务连续性。
集群管理仲裁关键技术
单节点故障在生产过程中，不可避免。CM 组件可根据探测到的状态进行仲裁，从而尽可能恢复集群可用性的过程。
以某个主 DN 故障为例，一次典型的仲裁流程包括：
① CM Agent 1探测DN主实例并发现故障
② CM Agent 1持续上报实例故障信息至CM Server
③ CM Server执行仲裁流程，选择DN备机升主
④ CM Server下发升主命令至CM Agent 2
⑤ CM Agent 2对实例执行升主操作
图5 集群管理仲裁过程
常见的故障类型包含磁盘故障、网络故障、下电故障、操作系统故障、其它故障（CPU故障）等。CM在选举过程中，遵从DN多数派。即，对于某一个DN分片来说，故障后的选主，需要得到大多数DN的投票，候选DN副本才可以被选中升主。仲裁规则主要依据两个原则：1） 任期（Term）大，且日志长的DN副本优先被选主 2） 同等条件下，静态主优先。
CM辅助不同组件故障情况下恢复过程
- CN 故障 （集中式部署时，无CM节点）
DDL 语句无法执行，DML 语句不受影响
通过将故障 CN 剔除，可保障 DDL 语句不受影响
仅支持集群内 CN 个数大于 3，且 1 个 CN 发生故障时剔除
- DN 故障
单点故障可自动恢复
主 DN 故障时，仲裁备 DN 升主继续提供服务
备 DN 故障时，主 DN 将日志和数据同步至从备，业务不受影响
- 主 GTM 故障
备 GTM 升主后继续提供服务
- 主 CM Server 故障
备 CM Server 接受多数派 CM Agent链接，升主后继续提供服务
异常检测
从业界经验来看，数据库实例可能处于故障、僵死、亚健康等状态。这些状态的出现概率逐级降低，但检测难度逐级增高。尤其是如何区分亚健康状态和系统繁忙状态，具有较大的挑战性。
CM 组件包含异常检测流程，可用于识别和处理网络不稳定、磁盘 IO 挂死、进程/线程僵死、进程频繁退出、实例状态时好时坏等场景，提高集群的稳定性和可用性。
以 DN 短链接检测为例，CM Agent 按照固定时间间隔与 DN 实例新建链接。如果与某个主 DN 链接失败或通过新链接无法执行 SQL 语句，则认为该 DN 发生 1 次 Hang 异常。如果多次出现异常，则会触发 Hang 检测机制，将该 DN 实例杀死并执行主备切换。目前常见的异常检测项有：
短链接建立
通过短链接执行 SQL 语句
IO 挂死
内存占用异常
基于Paxos协议复制实现DN副本自仲裁
GaussDB Kernel V5 采用基于Paxos协议主备副本复制协议，实现DN副本的自仲裁功能。关键技术方案如下图所示，其中DCF为GaussDB Kernel V5 基于Paxos协议的一致性复制组件。需包含日志复制、自仲裁选主等功能。
图6 DN自仲裁设计
关键技术方案要点：1）DN 副本自仲裁，缩短仲裁链路，减小RTO 2）采用Paxos一致性协议，保证DN副本间的一致性，避免备机由于日志分叉产生增量重建。
未来技术方案演进：1） DCF组件日志与数据库内核日志合一，减少对IO的占用。2） 采用Parallel Paxos协议或者多主的Paxos协议提升日志复制的吞吐量 3）通过RDMA/UB 网络优化主、备节点日志传输，提升日志复制性能。
