高可用定义
数据库高可用（High Availability），就是当部分节点故障时，系统仍能持续对外提供服务，业务不中断 、数据尽量不丢。
两个核心指标
三层高可用架构方案
第一层：接入层 — 应用怎么连数据库？
核心目标：屏蔽底层节点变更，应用零感知故障。
方案 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 两者兼顾但配置复杂。