MySQL高可用需主从复制、MHA切换和Keepalived VIP三层架构。主库开ROW格式binlog，从库配唯一server_id及relay_log；MHA通过SSH免密、配置文件和masterha_manager实现秒级切换；Keepalived绑定VIP并用notify脚本防脑裂；切换后须验证数据一致性、应用重连及原主库安全处理。
MySQL主从复制是高可用的基础
没有稳定的主从同步，后续的自动故障切换就无从谈起。部署前先确认主库已开启binlog，且格式为ROW；从库需配置server_id唯一、启用relay_log，并使用CHANGE MASTER TO指向主库的binlog位置。建议用GTID模式替代传统position方式，避免因跳过事务引发数据不一致。
MHA（Master High Availability）实现秒级主库切换
MHA是轻量、成熟、无需修改应用的MySQL高可用方案。它由Manager节点和Node节点组成，前者监控主库状态，后者部署在每台MySQL服务器上。关键操作包括：
- 所有节点配置免密SSH互信（MHA依赖SSH执行远程命令）
- Manager端编写配置文件app1.cnf，明确主库、候选主、从库角色及健康检查SQL
- 手动触发切换用masterha_master_switch --master_state=alive，故障自动切换需启动masterha_manager后台进程
- 切换后务必验证从库SQL线程是否正常运行，以及VIP是否漂移到新主库
Keepalived+VIP提供透明IP访问层
应用不应硬编码数据库IP。通过Keepalived在主库和候选主库上绑定同一个虚拟IP（VIP），应用只连这个VIP。当MHA完成主从切换后，由Keepalived接管VIP漂移：
- 主库Keepalived配置state MASTER，优先级设为100；备库设为BACKUP，优先级90
- 添加notify_master脚本，在获得MASTER角色时执行mysql -e "STOP SLAVE; RESET SLAVE ALL;"，防止旧主恢复后误成从库
- 检测脚本应检查MySQL进程、端口、以及SELECT 1响应，三者缺一不可
切换后必须做的三件事
一次成功的故障切换不等于高可用落地完成。运维人员需立即确认：
- 数据一致性：在新主库执行SHOW MASTER STATUS，对比各从库的Exec_Master_Log_Pos是否追平
- 应用连接恢复：检查连接池是否自动重连VIP，必要时重启应用或刷新DNS缓存
- 原主库处理：若原主库恢复，不要直接启动复制，先用pt-table-checksum校验差异，再按需重建从库或降级为新主的从库
