RDS for MySQL aurora 高可用架构
Aurora 是阿里云 RDS 的集中式高可用决策与切换平台，采用五层架构 + CDDT 闭环（Check → Diagnose → Decision → Treat），通过 Flow 引擎（XML 编排）驱动切换流程，支持 MySQL、PostgreSQL、MongoDB、Redis、SQLServer、PolarDB 等 11 种数据库引擎。对实例进行持续健康探测、故障诊断、自动切换、自愈修复。
一、五层架构
┌──────────────────────────────────────────────────────────────┐ │ ⑤ 接入与运维层 杜康控制台 / REST API / aurora-tool │ │ HA 日志页、切换详情弹窗、运维建议 │ ├──────────────────────────────────────────────────────────────┤ │ ④ 引擎适配层 aurora-mysql（最完整的引擎适配模块） │ │ (Engine Adapter) check/mysql/ · treat/mysql/ · ... │ ├──────────────────────────────────────────────────────────────┤ │ ③ 业务能力层 Check → Diagnose → Decision → Treat │ │ (Capabilities) Flow 引擎（XML 编排切换步骤序列） │ │ Notify · Integrate · Persistent │ ├──────────────────────────────────────────────────────────────┤ │ ② 平台框架层 aurora-framework（核心骨架） │ │ aurora-communicate（JGroups/Raft 选主） │ │ aurora-runtime / aurora-graphdb │ ├──────────────────────────────────────────────────────────────┤ │ ① 基础设施层 aurora-config / aurora-client / │ │ aurora-server / aurora-security │ └──────────────────────────────────────────────────────────────┘
二、核心闭环：CDDT（Check-Diagnose-Decision-Treat）
阶段 | 类比 | MySQL 场景下的具体行为 |
Check（探测） | 心电监护仪 | 定时连接 MySQL 执行 、 心跳检测，发现 、 、 等异常 |
Diagnose（诊断） | CT/MRI | 对异常做根因分析，通过 推断原因码，如 、 |
Decision（决策） | 主治医师 | 判断是否触发切换，检查熔断器（30 分钟 3 次熔断）、频率限制（20 分钟 5 次）、HA 是否被禁用等前置条件 |
Treat（修复） | 手术室 | 执行 MySQL 主备切换，包括 、 、 等步骤 |
┌─────────┐ MASTER_DOWN ┌──────────┐ 根因码 ┌─────────┐ │ Check │───────────────▶ │ Diagnose │ ───────────▶ │ Decision │ │ 探测层 │ (异常事件) │ 根因分析 │ (判定为可切换) │ 决策 │ └─────────┘ └──────────┘ └────┬────┘ ▲ │ │ │ 提交策略 │ ┌──────────┐ ▼ └──────────────────│ Treat │◀────────────── submit strategy 切换完成 │ 切换执行 │ Flow 引擎驱动 └──────────┘ ▲ │ XML 编排的步骤序列 │ 支持事务回滚、重试
三、 MySQL 切换标准步骤序列
当 Decision 判定需要切换后，Flow 引擎驱动以下步骤（记录在 aurora_switch_detail 表中）：
① diagnose → 诊断确认主库故障 ② FindTargetSlave → 找到最优备库（延迟最小、数据最完整） ③ CheckSlaveReplication → 检查备库复制状态 ④ CheckTimestampDelta → 检查主备时间戳差异 ⑤ SetMasterReadonly → 将原主库设为只读（防止脑裂） ⑥ MasterPosWait → 等待备库追平主库位点 ⑦ ChangeMaster → 执行 CHANGE MASTER TO，切换主备关系 ⑧ MaintainMetadata → 更新 MetaDB 元数据 ⑨ LinkApiSwitch/VipSwitch → VIP 漂移 / API 层面切换 ⑩ SaveSwitchProcedure → 持久化切换记录到 MetaDB
每个步骤的耗时（毫秒级） 都会记录在 aurora_switch_detail.switch_step_during 中，可在杜康控制台切换详情弹窗查看。
四、集群部署拓扑
Aurora 本身以多节点集群方式部署，通过 JGroups/Raft 实现选主和集群通信：
┌──────────────────────────────────────────────┐ │ MetaDB（共享元信息库） │ │ aurora_switch_log / aurora_list / bakowner │ │ cust_instance / aurora_request / ... │ └──────────────────────────────────────────────┘ ▲ ▲ ▲ │ │ │ 心跳每 1s 写一次 ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │Aurora-1 │◀────▶│Aurora-2 │◀────▶│Aurora-N │ │（主） │ JG/ │（备） │ Raft │（备） │ └─────────┘ └─────────┘ └─────────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────────────────────────────────┐ │ MySQL 实例（主 + 备 + 只读） │ │ Proxy 层（MaxScale / LVS） │ └──────────────────────────────────────────────┘
关键集群参数：
heartbeat_check_interval=1— 心跳写入 MetaDB 间隔（1 秒）ha_check_interval=60— Aurora 节点间健康检查间隔ha_autobalance_interval=600— 节点间负载均衡间隔
五、MySQL 引擎适配模块结构
aurora-mysql 是 Aurora 所有引擎适配中最完整的模块，遵循统一目录范式：
aurora-mysql/src/main/java/com/aliyun/rds/ha/cluster/ ├── check/mysql/ → MySQL 专属探测器（执行 SHOW SLAVE STATUS 等） ├── common/mysql/ → MySQL 公共逻辑 ├── cons/mysql/ → MySQL 常量（错误码、SQL 模板） ├── decision/mysql/ → MySQL 专属决策（主从延迟阈值判断） ├── diagnose/mysql/ → MySQL 专属诊断 ├── link/mysql/ → MySQL 连接驱动封装 ├── model/mysql/ → MySQL 专属数据模型 └── treat/mysql/ → MySQL 专属修复（切换、重搭、ResetSlave）
设计哲学：Framework 提供"如何切换"的抽象骨架，aurora-mysql 提供"对 MySQL 而言切换是什么"的具体实现，通过 SPI/Spring Bean 注册到 Framework。
六、核心元数据表（MetaDB）
Aurora 的切换记录和状态都持久化在 MetaDB 中，MySQL 场景下最常用的表：
表名 | 作用 |
| 切换主记录（状态、来源、原因、时间） |
| 切换详细信息（cause_code、cause_root、request_param） |
| 切换步骤明细（步骤名、耗时、结果、备注） |
| 实例 HA 状态（是否启用、被哪个 Aurora 节点接管） |
| 切换请求记录（来源、是否完成） |
| 节点心跳与实例归属关系 |
| 实例基本信息（名称、VIP、集群） |
七、部署目录（生产环境）
/usr/local/rds/aurora/package/ ├── config/ │ ├── conf.properties # 当前生效配置 │ ├── druid.properties # MetaDB 连接池 │ └── log4j.log # 日志配置 ├── jars/ # 所有 jar 包 ├── log/ │ ├── ha.log # ★ 系统主日志（切换决策、策略提交） │ ├── check.log # ★ 探测日志（MASTER_DOWN 等事件） │ ├── error.log # ★ 错误日志（异常堆栈） │ ├── framework.log # ★ 框架日志（选主、心跳、清理） │ ├── election.log # 选主日志（become leader / step down） │ └── introspect.log # 自检日志 └── service.sh # 启停管控
总结
RDS for MySQL 的 Aurora 高可用实现可以概括为：
探测层定时检查 MySQL 主库心跳，发现故障后上报异常事件
诊断层分析根因（主库宕机、挂起、网络超时等）
决策层检查熔断、频率限制等前置条件，决定是否切换
修复层通过 Flow 引擎驱动 10 步标准切换流程（FindTargetSlave → ChangeMaster → VipSwitch 等）
整个过程通过 JGroups/Raft 在 Aurora 集群节点间协调，切换记录持久化到 MetaDB
