MySQL高可用详细解析

核心基础：MySQL 复制机制

所有高可用方案都基于 Binlog 复制，分为三种同步模式：

1. 异步复制（默认）

原理：主库执行事务 → 写入 Binlog → 立即返回成功；从库异步拉取 Binlog 并重放。
优点：性能最好、无延迟阻塞。
缺点：主库宕机可能丢失未同步的 Binlog（RPO>0）。

2. 半同步复制（Semisync）

原理：主库提交前，至少等待一个从库确认收到 Binlog 并写入 Relay Log，超时（如 1s）自动退化为异步。
优点：大幅降低数据丢失风险。
缺点：写 RT 增加、网络敏感。

3. 组复制（MGR 同步）

原理：基于 Paxos 共识，事务需 多数派节点确认 才能提交。
优点：强一致（RPO=0）、自动选主、无数据丢失。
缺点：性能损耗、对网络延迟敏感（同机房 RTT<1ms）。

主从复制流程（三步曲）

主库：Dump 线程 发送 Binlog 给从库。
从库：IO 线程 接收并写入 Relay Log。
从库：SQL 线程 重放 Relay Log，保持数据一致。

二、主流高可用方案详解

方案 1：主从复制 + Keepalived（入门级）

架构：1 主 + 1/2 从 + Keepalived（VIP 漂移）。

故障检测 ：VRRP 心跳 + MySQL 状态探测（mysqladmin ping）。
切换：主库宕机 → 从库抢占 VIP → 应用无感知（秒级）。
优点：简单、低成本、易运维。
缺点：异步有丢数风险、半同步性能下降、无自动选主逻辑。
适用：中小业务、非核心系统、数据量 <1TB。

方案 2：MHA（Master High Availability）

架构：1 主 + 多从 + MHA Manager（独立节点）+ MHA Node（每 DB 节点）。

核心能力 ：
- 自动检测主库故障。
- 选主：选 数据最新、位点最前 的从库。
- 补数据：从宕机主库抢救 Binlog，补全差异。
- 切换：VIP 漂移、其他从库重定向到新主。
切换时间：10--30 秒。
优点：成熟稳定、支持任意引擎、数据丢失少。
缺点：依赖 SSH、无维护、云环境受限、不支持多主。
适用：传统主从、中大型业务、数据量 <5TB。

方案 3：MySQL Group Replication（MGR，官方推荐）

架构：3/5/7 奇数节点集群（单主模式推荐）。

核心原理（Paxos 共识） ：
1. 事务本地执行 → 生成 写集（WriteSet）。
2. 广播写集 → 多数派（n/2+1）验证通过 → 全局排序。
3. 所有节点提交 → 返回成功。
两种模式 ：
- 单主模式：一主写、多从读；自动选主、无冲突、生产首选。
- 多主模式：全节点读写；需冲突检测、易回滚、谨慎使用。
优点：强一致（RPO=0）、自动故障转移（<10s）、原生、去中心化。
缺点：仅 InnoDB、必须有主键、大事务 / 长事务敏感、网络要求高。
适用：核心交易、金融、云原生、数据量 <10TB。

方案 4：PXC/Galera Cluster（Percona XtraDB Cluster）

架构：多节点同步复制、全节点可读可写。

原理：基于 Galera 协议，事务认证（Certification）+ 全局排序。
优点：强一致、多主、秒级切换、读扩展好。
缺点：写性能随节点下降、DDL 阻塞集群、仅 InnoDB、资源消耗大。
适用：高并发写入、实时系统、多活部署。

方案 5：MySQL InnoDB Cluster（MGR 企业套件）

组件：MGR + MySQL Shell + MySQL Router（路由代理）。
能力：可视化管理、自动路由、故障自愈、读写分离、弹性扩缩。
定位：官方完整高可用栈，替代 MHA/PXC，生产首选标准化方案。

三、方案对比（核心指标）

表格

方案	一致性	RPO	RTO	写性能	运维	适用
主从 + Keepalived	最终一致	有丢失	秒--分钟	★★★★★	低	中小非核心
MHA	近强一致	极少丢失	10--30s	★★★★	中	传统主从
MGR/InnoDB Cluster	强一致	0	<10s	★★★	中高	核心金融
PXC/Galera	强一致	0	<5s	★★★	高	多写高并发

四、高可用关键机制

1. 故障检测

心跳：节点间定时探测（TCP/HTTP/MySQL 探针）。
阈值：连续 N 次失败 → 标记故障。
脑裂规避 ：奇数节点 + 多数派投票（MGR/PXC）。

2. 选主策略（核心）

GTID 优先：选择已执行事务最多、数据最新的节点。
权重优先：按硬件 / 配置权重选举。
位点优先：Binlog 位置最接近主库。

3. 数据一致性保障

GTID：全局事务 ID，保证事务唯一、不重复、可断点续传。
并行复制：从库多线程重放，降低延迟。
冲突检测：MGR/PXC 基于写集认证，并发修改同一行则回滚。

4. 读写分离（性能扩展）

中间件：ProxySQL、MaxScale、ShardingSphere。
路由：写→主、读→从；按延迟 / 负载均衡。
一致性读 ：关键业务强制读主、或 WAIT_FOR_EXECUTED_GTID 等待同步。

五、生产实践要点

1. 部署规范

节点数 ：MGR/PXC 用 3/5 奇数节点。
机房：同机房低延迟；跨机房用同城双活、避免跨城 MGR。
硬件：同配置、高 IO、低网络延迟。

2. 配置优化（MGR 示例）

ini

复制代码

plugin-load-add=group_replication.so
group_replication_single_primary_mode=ON   # 单主
group_replication_enforce_update_everywhere_checks=OFF
group_replication_gtid_assignment_block_size=1000000
group_replication_member_weight=50         # 选主权重

3. 监控指标

复制状态、延迟、事务队列、节点状态。
流量、RT、冲突率、大事务数。
磁盘、CPU、网络、连接数。

4. 故障演练

单节点宕机：自动切换验证。
网络分区：脑裂规避验证。
主库硬件故障：数据完整性验证。

5. 常见坑

大事务：MGR/PXC 长事务易超时、冲突、阻塞。
无主键：MGR 必须主键，否则性能极差。
跨城部署：延迟高 → 共识失败、性能暴跌。
脑裂：双主同时写 → 数据不一致。

六、选型建议

初创 / 中小业务 ：主从 + 半同步 + Keepalived → 简单低成本。
传统企业 / 主从存量 ：MHA → 平滑升级、兼容旧系统。
核心 / 金融 / 云原生 ：MySQL 8.0 + InnoDB Cluster（MGR） → 官方强一致、自动 HA。
多写 / 高并发实时 ：PXC → 多活、强一致、读写并行。

七、总结

MySQL 高可用从 主从异步（基础）→ 半同步（安全）→ MGR/PXC（强一致自动） 演进。生产优先选 InnoDB Cluster（MGR 单主），兼顾一致性、可靠性与运维成本；非核心可用主从 + Keepalived；传统架构可用 MHA。最终需按业务一致性要求、性能、规模、运维能力综合选型。