MySQL高可用没有单一最优解，只有最适合业务场景的方案：主从复制+Keepalived适合中小团队快速上线但存在RPO风险；MHA实现自动选主但运维复杂且Manager单点；MGR基于Paxos保障RPO=0但性能损耗大；ProxySQL提升读写分离灵活性但不解决故障切换。
MySQL高可用没有“标准答案”，只有匹配业务场景的合理组合。单靠主从复制不能算高可用，必须叠加自动故障探测、服务地址切换、一致性保障等能力才算落地。
主从复制 + Keepalived/VIP 是最简可行方案
适合中小团队快速上线，成本低、链路短、故障路径清晰。
-
Keepalived监控mysqld进程和端口，主库挂掉后秒级漂移 VIP 到从库，应用无感切换（前提是连接用的是 VIP，不是直连 IP） - 必须关闭从库的
read_only = OFF（仅在提升为主库时临时打开），否则START SLAVE会失败 - 常见坑：网络抖动触发误切；VIP 漂移后旧主库恢复时未设为只读，导致双写；
server-id冲突造成复制中断 - 不解决复制延迟问题——如果主库刚提交事务就宕机，而从库还没同步完，VIP 切过去就会丢数据
MHA 能自动选主但运维负担重
它补上了主从架构里“谁来判断主库死了”“谁来执行 CHANGE MASTER TO”这两个关键缺口。
-
mha4mysql-manager和mha4mysql-node必须分别部署，manager 节点本身要高可用（否则单点失效即瘫痪） - 依赖 SSH 免密登录，权限配置稍复杂；升级 MySQL 版本时需同步验证 MHA 兼容性（比如 8.0.33+ 对
mysql.session账户有新要求） - 默认只支持一主多从，不支持多主；failover 后不会自动修复原主库的复制关系，得手动
CHANGE MASTER回去 - 日志里出现
Failed to get master binlog coordinates多半是主库SHOW MASTER STATUS权限没给够，或 binlog 被 purge 掉了
MGR（Group Replication）是原生强一致方案
MySQL 5.7.17+ 内置，基于 Paxos 协议实现多节点共识，适合对数据零丢失敏感的场景。
- 必须用
gtid_mode = ON+enforce_gtid_consistency = ON，且所有节点binlog_format = ROW - 单主模式下写入只发生在 primary 节点，secondary 节点只读；切换由组内投票决定，无需外部组件
- 性能损耗明显：事务提交要等多数派确认，QPS 比单机下降 20%~40%，尤其跨机房部署时延迟放大
- 常见报错
ERROR 3092 (HY000): The slave is connecting using CHANGE MASTER TO...是因为 MGR 不允许混用传统复制命令，必须用START GROUP_REPLICATION
ProxySQL + 主从是读写分离最灵活的组合
它不解决故障切换，但把“怎么分发请求”这件事做到极致，配合其他 HA 组件效果更稳。
-
mysql_servers表里设置hostgroup_id区分主库（hg 10）和从库（hg 20），再用mysql_query_rules匹配 SQL 类型路由 - 写操作必须带
FOR UPDATE或显式指定/*+ MAX_EXECUTION_TIME(1000) */才能进规则，否则可能被误判成读请求发到从库 - 从库健康检查靠
mysql_server_read_only状态字段，但该字段可能滞后——建议额外加SELECT @@read_only做双重校验 - 不要把 ProxySQL 当成 HA 中间件：它不感知主库是否真挂了，只按配置转发；主库宕机后，得靠外部脚本调用
UPDATE mysql_servers SET status='OFFLINE_SOFT'手动下线
真正难的从来不是搭出一个“能切”的架构，而是厘清“切的时候能接受多少数据丢失”“切换窗口能不能压到 30 秒内”“运维同学半夜能不能看懂告警含义”。这些细节藏在配置参数、监控指标、切换脚本的每一行里，而不是方案名字里。
