一、故障恢复依赖关系
GaussDB集群的故障恢复遵循严格的依赖路径：
ETCD → CMS → GTM/DN → CN
集群启动/故障恢复依赖路径：
-
crontab 拉起 om_monitor
-
om_monitor 拉起 CMAgent 和 ETCD
-
CMAgent 拉起 CN、DN、GTM、CMServer
-
ETCD 通过 Raft 协议为 CMServer 提供仲裁基础
-
CMServer 仲裁 GTM、DN
-
CMServer 对 CN 进行剔除/加回
二、CN 实例故障仲裁与切换
CN 故障，RTO ≤ 30 秒
| 步骤 | 描述 | 耗时 |
|---|---|---|
| A | 分布式数据库正常运行 | --- |
| B | Agent 探测到 CN 故障 | 1 秒 |
| C | Agent 尝试拉起 CN，如果拉起则恢复正常；如果拉不起则转下一步 | 25 秒 |
| D | CM 仲裁触发自动 CN 剔除，将该 CN 信息从所有其他 CN 节点中删除 | 3 秒 |
| E | 数据库恢复正常状态，DDL 可以执行成功 | 约 1 秒 |
CN 剔除步骤：
-
CM 检测到 CN 连续故障时长超过 25 秒，CMS 发起 CN 剔除操作，CN 处于 Deleting 过程中
-
CM 更新其他 CN 节点的
pgxc_node系统表 -
将 CN 隔离状态保存到分布式存储组件（ETCD）
-
数据库状态恢复，CN 可以执行 DDL 成功
业务影响： 正在通过故障 CN 执行的业务失败；在检测 CN 的隔离期，通过 JDBC 发往该 CN 的新连接会失败。JDBC 定期（默认 10 秒，可配置）查询可用 CN 并分配连接。
三、DN 实例故障仲裁与切换
3.1 DN 主故障
DN 主故障，RTO ≤ 约 10 秒
| 步骤 | 描述 | 耗时 |
|---|---|---|
| A | 分布式数据库正常运行 | --- |
| B | Agent 探测到某分片的 DN 主故障 | 1 秒 |
| C | Agent 尝试拉起 DN 主，如果拉起则继续为主，如果拉不起则进入选新主流程 | 6 秒 |
| D | CM 仲裁 DN 新主，并触发备升主 | 2 秒 |
| E | 备机连接主机，应用恢复连接 | 2 秒 |
DN 仲裁选主过程：
-
DN 主实例故障
-
CMS 等待 6 秒，若原主能恢复则不需要选新主
-
超过 6 秒原主状态没有恢复，CMS 发起选择新 DN 主，并行给备选副本发送 Lock1 命令
-
从锁住的多数派副本中，选择 term/Lsn 最大的副本，并通知升主
-
CMS 发起 Lock2 命令给备机，告知新主
-
CMS 发起 unlock 解锁
3.2 DN 角色仲裁规则
DN 实例仲裁保证集群中有 DN 主实例正常提供服务。CM Server 通常在实例故障一段时间后再下发仲裁结果（延迟仲裁机制），避免发生瞬时故障时立即仲裁主备倒换。
DN 实例角色状态：
| 字段 | 取值 |
|---|---|
| 角色 | Primary（主）、Standby（备）、Pending（待仲裁）、Unknown（未知） |
| 状态 | Normal、Starting、Need repair、Waiting Promoting、Promoting、Demoting、Building、Build failed、Manually stopped、Disk damaged、Port used |
| Build reason | Connecting、Disconnect、WalSegment removed |
一次典型的仲裁流程：
-
CM Agent 1 探测 DN 主实例并发现故障
-
CM Agent 1 持续上报实例故障信息至 CM Server
-
CM Server 执行仲裁流程，选择 DN 备机升主
-
CM Server 下发升主命令至 CM Agent 2
-
CM Agent 2 对实例执行升主操作
3.3 主-备-从备高可用
GaussDB(DWS) 采用主-备-从备三副本高可用技术：
-
正常状态
：主机和备机通过日志流复制和数据页流复制进行强同步；主机与从备仅保持连接，不发送日志和数据
-
备机故障
：主机自动感知，将未完成同步的日志和数据发送给从备，保持主从强同步。切换在底层 HA 实现，事务层不感知
-
主机故障
：CM 感知并仲裁备机升主，升主后的备机连接从备进行主从强同步
四、GTM 实例故障仲裁与切换
4.1 GTM 主故障
GTM 主故障，RTO ≤ 10 秒
| 步骤 | 描述 | 耗时 |
|---|---|---|
| A | 分布式数据库正常运行 | --- |
| B | Agent 探测到 GTM 主故障 | 1 秒 |
| C | Agent 尝试拉起 GTM 主，如果拉起则继续为主，如果拉不起则进入选主流程 | 3 秒 |
| D | CM 仲裁 GTM 备升主 | 2 秒 |
| E | 恢复 CN 的连接请求 | 约 2-3 秒 |
GTM 仲裁选主过程：
-
GTM 主故障
-
判断 GTM 备与主的连接状态
-
若 GTM 备与主连接断开，直接判定上报节点升主
-
若 GTM 备与主保持连接，达到超时时间前，触发主备切换，并杀掉原主
4.2 GTM 主备架构
正常主备倒换（手动）：
-
备 GTM 收到升主命令，连接主 GTM，让主 GTM 停止执行新业务
-
备 GTM 向主 GTM 查询 xid 和 sequence，并覆盖进程内的值
-
备 GTM 让主 GTM 降备，备 GTM 备份内存中 xid 和 sequence
-
GTM 升主，开始执行业务
自动故障切换（failover）：
-
主 GTM 故障或损坏，无法被 CMAgent 拉起
-
CMAgent 检测到主 GTM 无法连接，上报至 CMServer
-
如果此时备 GTM 状态正常，CMServer 执行 failover 流程，仲裁备 GTM 升主
-
CMAgent 给备 GTM 发送升主信号，备 GTM 升主后开始执行业务
GTM 同步状态：
| 同步状态 | 说明 |
|---|---|
| SYNC_GTM_ON（强同步） | 集群启动或 GTM 异常恢复后，CM 检测到 GTM 主备正常时设置。主 GTM 同步备 GTM 成功则返回，否则继续尝试直到同步成功 |
| SYNC_GTM_AUTO（异步） | 集群启动后所有 GTM 的初始状态。当主/备 GTM 无法正常工作时，另一个存活的 GTM 会切换到该状态。主 GTM 执行完业务后直接发送指令给备 GTM，无论同步成功或失败 |
重要说明： 主 GTM 不与备 GTM 进行数据同步，备 GTM 仅尝试与主 GTM 进行连接状态校验。GTM 主备中需要同步的数据（如 host、port、xid、timeline、sequence）都备份在 ETCD 上。
五、CM（CMServer）实例故障仲裁与切换
CM 主故障，RTO ≤ 10 秒
| 步骤 | 描述（ETCD 模式） | 耗时 |
|---|---|---|
| A | 分布式集群管理状态正常 | --- |
| B | CMS 备检测 CMS 主与 ETCD 心跳超时 | 3 秒 |
| C | CMS 备进入仲裁新主流程，判断主 KEY 是否已被写入 ETCD 中 | 2 秒 |
| D | 往 ETCD 的 KEY 写入本节点 ID，并由备机升主 | 5 秒 |
| E | 候选 CMS 备升主完成切换，提供集群查询服务 | --- |
CMS 仲裁选主过程：
-
CMS 主节点异常
-
尝试拉起 CMS 进程，并触发选主过程
-
CMS 依赖的组件选主成功：
-
etcd 模式
：etcd 先选主，CMS 执行选主流程
-
dcc 模式
：dcc 先选主，CMS 跟随选主
-
-
CMS 选主成功
六、节点故障仲裁与切换
节点故障，RTO ≤ 30 秒
| 步骤 | 描述（ETCD 模式） | 耗时 |
|---|---|---|
| A | 分布式数据库正常运行 | --- |
| B | 节点被停止、掉电、网络断开等（假设各个节点的主实例都在故障节点上） | 3-6 秒 |
| C | ETCD 重新选主 | 5 秒 |
| D | CMS 选新主并仲裁新的 GTM、DN 节点 | 6 秒 |
| E | CN 恢复，应用侧连接恢复 | 10 秒 |
组合故障场景下的恢复路径：
1. etcd 恢复并选主
2. cms 恢复并选主
3. gtm/dn 恢复并选主
4. cn 恢复并选主七、AZ 故障仲裁与切换
生产机房故障，RTO ≤ 约 1 分钟
| 步骤 | 描述 | 耗时 |
|---|---|---|
| A | 分布式数据库正常运行 | --- |
| B | 网络故障检测 | 约 30-40 秒 |
| C | ETCD 备升主 | 10 秒 |
| D | CMS 备升主 | 10 秒 |
| E | CMS 主获知 GTM 和 DN 主故障，并行仲裁 GTM 备升主、各分片的 DN 备升主 | 10 秒 |
| F | CN 恢复，应用侧的连接 | 约 2-5 秒 |
| G | 应用侧连接恢复并恢复业务执行 | --- |
AZ 网络故障仲裁与切换步骤：
1. 网络故障检测
2. 仲裁本 AZ 启停
3. 触发新的选主流程
4. etcd 恢复并选主
5. cms 恢复并选主
6. gtm/dn 恢复并选主
7. cn 恢复并选主AZ 网络故障类型：
-
双边网络隔离
：两个 AZ 之间网络完全断开
-
单边网络隔离
：一个 AZ 无法访问其他 AZ，但其他 AZ 之间可通信
3AZ 强启动与加回：
当 AZ1、AZ2 任意一个 AZ + 仲裁 AZ 故障（少数派出现时），支持人工强启：
-
约束：强启动的 AZ 在故障前是集群中正常的 AZ，否则数据不是最新的，会引起数据丢失
-
离线完成强启动过程，防止强启期间故障恢复引起多主可写的问题
-
多数派恢复后，会自动以备机形式加入集群，保持数据同步，之后需要执行加回操作使数据库恢复到完全正常状态
八、总结：各组件故障 RTO 对比
| 故障类型 | RTO 目标 | 核心恢复机制 |
|---|---|---|
| CN 故障 | ≤ 30 秒 | Agent 尝试拉起 → 25 秒未恢复则 CM 自动剔除 |
| DN 主故障 | ≤ 10 秒 | Agent 尝试拉起 6 秒 → CM 仲裁备升主（选 term/Lsn 最大副本） |
| GTM 主故障 | ≤ 10 秒 | Agent 尝试拉起 3 秒 → CM 仲裁备升主 |
| CM 主故障 | ≤ 10 秒 | CM 备检测心跳超时 → ETCD 写入 KEY → 备升主 |
| 节点故障 | ≤ 30 秒 | ETCD 选主 → CMS 选主 → GTM/DN 选主 → CN 恢复 |
| AZ 故障 | ≤ 1 分钟 | 网络检测 → ETCD → CMS → GTM/DN → CN 逐层恢复 |
转载：星辰明的絮语