MySQL主库宕机后自动故障转移需构建高可用集群，MGR+Router实现秒级选主与无感切换，MHA适用于传统主从轻量切换，ProxySQL通过健康检查模拟故障转移，均依赖GTID、半同步等基础配置保障。
MySQL主库宕机后的自动故障转移与选主，核心不是靠“配置单个数据库”，而是构建一个具备共识决策和路由感知能力的高可用集群。纯原生主从不支持自动选主，必须引入额外组件协同工作。
用MGR + MySQL Router实现真正自动选主与无感切换
MGR（MySQL Group Replication）是MySQL官方提供的基于Paxos的组复制方案，它让多个节点组成一个逻辑集群，内部自动维护成员状态、检测故障、发起选主并达成数据一致性共识。
- MGR集群中任意节点宕机，剩余健康节点会在几秒内完成新主选举，无需外部干预
- 事务提交需多数节点确认（quorum），保障RPO≈0，比半同步更可靠
- MySQL Router部署在应用侧，监听MGR元数据服务（通过performance_schema或专用端口），实时感知主角色变化
- 应用只连Router提供的固定读写端口（如6446写、6447读），Router自动把写请求转发给当前主，读请求负载到所有可读节点
- 主库宕机后，MGR选出新主，Router在10秒内更新路由表，应用连接不中断、无需改配置
用MHA做轻量级自动切换（适合传统主从环境）
MHA（Master High Availability）是社区成熟方案，适用于已有主从架构、暂不升级MGR的场景。它依赖外部监控+脚本执行，非完全自治，但稳定可控。
- 需部署MHA Manager节点，持续检查主库SSH、MySQL进程、复制延迟等健康指标
- 主库失联后，MHA自动挑选延迟最小、GTID最全的从库作为候选主，并校验relay log完整性
- 执行STOP SLAVE、RESET SLAVE ALL、提升为MASTER、重置其他从库指向新主等全套操作
- 必须配合master_ip_failover脚本完成VIP漂移或DNS更新，否则应用仍连不到新主
- 关键前提：所有节点间SSH免密互通、mysql用户有sudo NOPASSWD权限、SQL线程必须RUNNING且Seconds_Behind_Master可读
用ProxySQL + 自定义探测实现灵活读写分离与故障转移
ProxySQL是高性能代理层，本身不选主，但可通过健康检查+权重调度+自动下线机制模拟故障转移效果。
- 配置monitor模块定期执行SELECT 1或SHOW SLAVE STATUS，识别主从角色及延迟
- 设置hostgroup：写流量固定发往hostgroup 10（主库），读流量轮询hostgroup 20（从库）
- 当主库探测失败，ProxySQL自动将其从hostgroup 10中移除；若只剩一个从库在线，可临时允许其接受写请求（需提前开启read_only=OFF）
- 需配合外部脚本（如crontab调用curl触发failover）来真正执行CHANGE MASTER TO，ProxySQL只负责流量接管
- 优势是响应快（秒级）、支持复杂路由规则；缺点是不保证强一致，适合对RPO要求不苛刻的业务
关键配置前提不能跳过
无论选哪种方案，以下基础配置是自动切换成功的底层保障：
- 主从必须启用GTID（gtid_mode=ON + enforce_gtid_consistency=ON），避免位点计算错误
- 推荐使用半同步复制（rpl_semi_sync_master_enabled=1），降低主库宕机时的数据丢失风险
- 所有节点server-id唯一，binlog_format=row，确保复制可靠性
- 从库务必设置read_only=ON（super_read_only=ON更佳），防止误写破坏一致性
- 监控项至少包括：MySQL进程存活、复制线程状态、Seconds_Behind_Master、GTID_EXECUTED比对
