MySQL 高可用本质上就是一句话：
避免单点故障 + 故障时能自动切换 + 切换过程业务无感或可接受
下面我给你从“面试官视角 + 工程落地视角”把这件事讲透。
⭐ MySQL 高可用体系：从低到高的四种级别
1）主从复制（最基础，不能算真正高可用）
- 主库挂了，从库还在，但 不能自动切换
- 要人工把从库提升为主库
- 复制有延迟，容易产生数据丢失（秒级）
👉 这只是“备份方案”，不是高可用。
2）基于复制的高可用（真正能用）
方案 A：MHA（MySQL High Availability）
优点：
- 经典方案，生产验证多
- 主库挂了会自动选举新主库
- 支持半同步，数据可控
缺点：
- 已不再积极维护
- 依赖外部脚本
- 架构复杂（VIP + Manager）
适用：
- 老系统
- 想要稳定但对运维依赖高的团队
方案 B：Keepalived + 双主（Active/Standby）
思路：
- 两个主库，只有一个对外（VIP）
- Keepalived 监控主库，不行了就漂到另一台
优点：
- 简单
- 成本低
缺点：
- 双主存在冲突风险
- 数据一致性靠复制
适用：
- 银行业等喜欢双主的传统企业
3）基于 Group Replication 的 InnoDB Cluster（官方标准 HA）🔥 推荐
由 MySQL 官方提供：
- Group Replication（核心）
- Router（自动路由）
- Shell（管理工具）
优势很明显：
- 原生支持高可用
- 自动故障切换
- 强一致性模式（单主模式）
- 水平扩展方便
你可以把它理解成“更现代、更强的 MGR + Proxy”。
这是 8.x 默认推荐的 HA 架构。
4）云厂商的高可用架构（最稳定，最贵）
比如：
- AWS Aurora MySQL
- TencentDB
- Aliyun RDS
这些都是大厂用心调过的，有以下特点：
- 秒级故障切换（通常 10-30 秒）
- 主从间延迟极低（自研协议）
- 自动检测 + 自动恢复
- 可以跨 AZ
你几乎不用担心 HA，只需要付钱。
⭐ MySQL 高可用的核心技术点（面试官最爱问）
1. 主从复制（异步 / 半同步 / 强同步）
必须要知道：
| 模式 | 数据是否可能丢失 | 延迟 | 应用概率 |
|---|---|---|---|
| 异步 | 是 | 小 | 90%场景 |
| 半同步 | 极低 | 中 | 金融、电商 |
| 强同步 | 理论不丢 | 大 | 几乎不用 |
2. 健康检查 & 故障探测
高可用必有监控机制：
- 心跳检测
- 存活检查
- 延迟检测
- 复制状态检查
比如 MHA 会检查：
- 主库是否挂了
- 哪个从库最“新”
- 哪个具备提升为主库的条件
3. 自动选主
需要根据：
- 复制延迟
- 日志位置（relay-log / binlog pos）
- 服务器健康度
- 是否具备读写权限
官方的 Group Replication 内置了投票机制。
4. 路由层（非常关键）
要做到“切换时业务无感”，必须有一个组件：
- MySQL Router（官方）
- ProxySQL（企业常用）
- LVS / HAProxy
作用：
- 不让应用直接连数据库，而是连代理
- 代理判断写请求该发到哪，读请求发到哪
- 故障时自动重连正确节点
⭐ 面试官会重点听你说什么？
我给你一个“黄金回答模板”，你可以直接用：
✔ 黄金回答（你可以在面试中完整说出来）
MySQL 高可用主要通过“复制 + 故障检测 + 自动切换 + 路由”来实现。
常见的 HA 架构包括 MHA、Keepalived 双主、以及 MySQL 官方的 InnoDB Cluster。
我个人更推荐 InnoDB Cluster，因为它基于 Group Replication，可以提供真正的自动选主和一致性保证，再配合 MySQL Router 实现业务的透明切换。
在设计 MySQL 高可用时，我会重点关注 4 点：
- 复制模式：确认是否使用半同步，降低数据丢失风险。
- 故障检测机制：确保主库宕机能在几秒内被发现。
- 自动切换策略：以延迟最小的从库为新的主库。
- 路由层设计：使用 Router/ProxySQL 让业务无感切换，避免修改连接串。
在云上，我会优先选择云数据库的原生 HA（如 AWS Aurora 或阿里 RDS），因为它们延迟低、切换快、可靠性高，能减少大量运维成本。