一句话总结
MySQL 高可用架构演进：主从 + Keepalived（VIP 漂移）→ MHA（自动故障转移）→ MGR 组复制（多主、Paxos 协议）→ InnoDB Cluster（MySQL 官方方案）。中小公司用 MHA 或 Orchestrator，大厂自研或使用 MGR/InnoDB Cluster。核心指标：RTO（恢复时间）和 RPO（数据丢失量）。
初级理解
高可用架构演进
| 方案 | 原理 | RTO | RPO | 复杂度 |
|---|
| 主从 + Keepalived | VIP 漂移到从库 | 分钟级 | 可能丢数据 | 低 |
| MHA | 监控主库，自动选新主+数据补偿 | 30秒~1分钟 | 几乎不丢 | 中 |
| Orchestrator | 拓扑管理+自动故障转移 | 30秒~1分钟 | 几乎不丢 | 中 |
| MGR（组复制） | Paxos 协议，多主写入 | 秒级 | 不丢 | 高 |
| InnoDB Cluster | MGR + MySQL Router + MySQL Shell | 秒级 | 不丢 | 高 |
一句话总结：主从+Keepalived 最简单，MHA 最常用，MGR 最先进。
中级深入
MHA（Master High Availability）
MHA 由管理节点（Manager）和部署在每个 MySQL 节点上的 Node 组成。Manager 监控主库，主库宕机时自动执行故障转移：
1. 选一个数据最新的从库作为新主库
2. 从宕机主库的 binlog 中补偿差异数据到新主库
3. 其他从库切换到新主库
4. VIP 漂移到新主库
# MHA 架构示意
# Manager 节点（独立部署）
# ├── 监控主库心跳
# ├── 主库宕机 → 触发故障转移
# └── 选新主 + 数据补偿 + 切换
# 优点：
# 1. 自动故障转移，RTO 30秒~1分钟
# 2. 数据补偿机制，RPO 几乎为 0
# 3. 支持在线切换（计划内切换）
# 缺点：
# 1. 需要独立部署 Manager
# 2. 至少 3 台机器（1主2从）
# 3. 不适用于 GTID 不完整的场景
MGR（MySQL Group Replication）
MySQL 5.7.17+ 官方推出的组复制，基于 Paxos 协议实现多主复制。所有节点组成一个复制组，事务提交需要组内多数节点同意。
# MGR 模式
# 单主模式（Single-Primary）：只有一个节点可写，其他只读
# 多主模式（Multi-Primary）：所有节点都可写
# 核心机制：
# 1. 事务提交 → 广播到组内所有节点
# 2. 多数节点确认 → 事务提交成功
# 3. 冲突检测：多主模式下检测写冲突
# 优点：
# 1. 自动故障转移（秒级）
# 2. 数据零丢失（RPO=0）
# 3. 多主写入（多主模式）
# 缺点：
# 1. 至少 3 个节点
# 2. 网络延迟敏感
# 3. 写入性能略低于异步复制
中级要点：MHA 是成熟方案，MGR 是官方新方案；MHA 异步复制可能丢少量数据，MGR 基于 Paxos 不丢数据。
高级拓展
Orchestrator — 拓扑管理 + 自动故障转移
Orchestrator 是 GitHub 开源的 MySQL 高可用工具，提供可视化拓扑管理和自动故障转移。
# Orchestrator 特点
# 1. 自动发现 MySQL 拓扑结构
# 2. 可视化 Web 界面
# 3. 支持多种故障转移策略
# 4. 支持计划内切换（Graceful Master Takeover）
# 5. 支持中间主库故障恢复
# 与 MHA 对比
# MHA: 专注故障转移，功能单一
# Orchestrator: 拓扑管理 + 故障转移 + 可视化，功能更全
脑裂问题与解决
脑裂：主库实际未宕机但被判定为宕机（如网络分区），新主库被提升，导致两个主库同时写入。
# 脑裂解决方案
# 1. 强制关闭旧主库（STONITH: Shoot The Other Node In The Head）
# - MHA 通过 SSH 执行 shutdown_script 关闭旧主库
# 2. 法定人数（Quorum）
# - MGR 要求多数节点同意才能提交事务
# - 网络分区后少数派自动降级为只读
# 3. 仲裁节点
# - 部署一个轻量级仲裁节点，不存数据只投票
实战场景
场景：主从 + Keepalived 实现高可用
# Keepalived 配置（主库）
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
virtual_ipaddress {
192.168.1.200/24 # VIP
}
track_script {
chk_mysql # 监控 MySQL 存活
}
}
# MySQL 监控脚本
# /etc/keepalived/chk_mysql.sh
#!/bin/bash
mysql -u root -p'password' -e "SELECT 1" > /dev/null 2>&1
exit $?
# 应用连接 VIP
spring.datasource.url=jdbc:mysql://192.168.1.200:3306/db
# 主库宕机 → VIP 漂移到从库 → 从库提升为主库
面试模拟
面试官：你们公司 MySQL 高可用怎么做的？
你：我们用的是 MHA + 半同步复制。一主两从，MHA Manager 独立部署监控主库。主库宕机后 MHA 自动选数据最新的从库提升为主库，补偿差异数据，VIP 漂移，整个过程约 30 秒。半同步复制保证至少一个从库收到 binlog，RPO 几乎为 0。
面试官：MGR 和主从复制有什么区别？
你：1）主从复制是异步/半同步，MGR 基于 Paxos 协议是强一致的；2）主从复制有主从角色之分，MGR 多主模式下所有节点可写；3）主从复制故障转移需要外部工具（MHA），MGR 内置自动故障转移；4）MGR 要求至少 3 个节点，对网络延迟更敏感。