如何设计一个高可用的MySQL方案？

如何设计一个高可用的MySQL方案？

高可用定义

数据库高可用（High Availability），就是当部分节点故障时，系统仍能持续对外提供服务，业务不中断、数据尽量不丢。

两个核心指标

高可用的本质就是主库故障时从库快速接管，数据尽量不丢。所有方案都围绕 RTO 和 RPO 这两个目标设计。

三层高可用架构方案

第一层：接入层 — 应用怎么连数据库？

核心目标：屏蔽底层节点变更，应用零感知故障。

方案 1：VIP + Keepalived（经典方案）

# 主库绑定虚拟 IP：192.168.1.100
# 主库挂了，Keepalived 自动把 VIP 漂移到从库
# 应用配置连的是 VIP，无需改代码

原理：应用只连虚拟 IP，不感知真实物理机。主库宕机 IP 漂移，从库接管。

方案 2：ProxySQL（高并发首选）

-- ProxySQL 自动探测后端主库状态
-- 主库宕机自动熔断，写流量切到新主库
-- 同时集成读写分离、连接池、SQL 限流

接入层只管让应用不感知故障，不管数据怎么同步。

第二层：服务层 — 数据怎么同步？（重点）

核心目标：平衡性能、可用性、数据一致性。

方案 1：异步复制（默认，性能优先）

-- 主库写完直接返回，不等待从库确认
-- 吞吐最高，但主库宕机可能丢数据（RPO > 0）
SHOW VARIABLES LIKE 'rpl_semi_sync_master_enabled';
-- OFF = 异步复制

方案 2：半同步复制（数据安全优先）

-- 主库等至少一个从库收到 Binlog 并写入 Relay Log，才返回成功
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 10000; -- 10秒超时降级异步

权衡：已确认的数据几乎不丢（RPO ≈ 0），但等从库确认有延迟，吞吐量小幅下降。适合订单、支付等核心业务。

方案 3：MGR 组复制（官方新标准，新项目首选）

-- MySQL 5.7+ 原生高可用，无需第三方组件
-- 组内节点多数派选举，自动故障检测、自动切换
SELECT * FROM performance_schema.replication_group_member_stats;

核心优势：

• 自动防脑裂：少数派节点自动断连，杜绝双主写入。
• 数据强一致：事务必须在组内多数节点确认才能提交。

方案 4：MHA（旧项目维护）

基于 Perl 脚本的第三方方案，适配 MySQL 5.6 及以下老旧版本。主库故障后自动选最新从库提升为主，搭配 VIP 漂移完成切换。开源版已停止维护，新项目优先选 MGR。

服务层的选择本质是 RTO 和 RPO 的权衡。异步快但不安全，半同步安全但有延迟，MGR 两者兼顾但配置复杂。

第三层：数据层 — 数据怎么永久不丢？

核心目标：应对节点级、机房级故障，实现任意时间点恢复。

1. 物理全量热备：Percona XtraBackup 无锁热备，不影响线上业务。
2. Binlog 增量归档：实时归档到对象存储，结合全量备份实现 PITR（任意时间点恢复）。
3. 异地多活容灾：跨机房实时同步 Binlog，抵御单机房断电灾难。

# 物理热备份示例
xtrabackup --backup --target-dir=/backup/full

监控体系

故障切换策略

新旧架构选型规则

MySQL 高可用不是单一技术，是接入层无感切换 + 服务层可靠同步 + 数据层兜底容灾 + 全链路监控的完整体系。没有万能方案，根据业务 RTO 和 RPO 诉求选型，平衡性能与数据安全，就是最优架构。

额外拓展

第一，脑裂是高可用最大致命风险，传统 Keepalived 双主必须搭配 Zookeeper/etcd 仲裁节点，MGR 多数派共识机制可天然防脑裂；
第二，MHA 适配老旧版本但已停止维护，新项目优先 MGR + InnoDB Cluster 官方生态；
第三，高可用架构无法兜底劣质 SQL，慢 SQL、大事务、无主键表引发的延迟会直接击穿所有高可用策略，日常优化和架构建设必须并行。