MySQL主从复制未配妥时，Keepalived无法保障高可用；必须确保主从同步稳定、read_only开启、健康检查精准、监听与权限配置正确，并避免双主架构风险。
MySQL主从复制没配好，Keepalived再稳也白搭
Keepalived本身不处理MySQL读写分离，它只管VIP漂移；真正分担读写压力的是上层架构（比如中间件、应用路由或从库直连）。如果主从延迟大、从库同步中断，或者read_only=OFF没设，VIP切过去后立刻写入从库，数据就乱了。
实操建议：
- 确认主从已稳定运行至少24小时，
Seconds_Behind_Master持续为0或个位数 - 所有从库必须设置
read_only=ON（但保留super_read_only=OFF以便维护） - 主库
binlog_format必须是ROW，避免语句级复制导致的不一致 - 用
SHOW SLAVE STATUS\G检查Slave_IO_Running和Slave_SQL_Running均为Yes
Keepalived配置里最容易漏掉的健康检查项
默认的vrrp_script只ping通IP就认为服务正常，但MySQL进程可能卡死、端口被占、或者拒绝新连接——这时VIP还在从库上挂着，流量照进，查询全挂。
实操建议：
- 写一个轻量健康脚本，例如检查
mysql -h127.0.0.1 -P3306 -uhealth -p'xxx' -e "SELECT 1"是否返回0 - 在
vrrp_script中用interval 2（别设成5秒以上），fall 2，rise 2，避免抖动误切 - 脚本里加超时：
timeout 3，防止TCP hang住阻塞整个check流程 - 确保
keepalived用户有执行该脚本的权限，且mysql客户端已加入PATH
主库宕机后VIP自动切到从库，但应用连不上怎么办
常见现象是VIP飘过去了，mysql -h VIP连不通，或者报Access denied for user。根本原因不是Keepalived没起作用，而是MySQL监听绑定、账号权限或防火墙没对齐。
实操建议：
- MySQL必须监听
0.0.0.0:3306（而非127.0.0.1），否则VIP流量进不来 - 创建账号时用
'appuser'@'%'或'appuser'@'10.0.0.%'，不能只建'appuser'@'localhost' - 检查
bind_address配置项：设为0.0.0.0或注释掉；设为127.0.0.1会导致VIP失效 - 确认iptables/firewalld放行VIP所在网段对3306的访问，不只是本机IP
双主+Keepalived看似高可用，实际埋雷最多
很多团队图省事配双主（Active-Active），再用Keepalived做VIP漂移。但MySQL原生不支持冲突自动解决，auto_increment_offset和auto_increment_increment稍配错，主键就重复；事务并行写入还可能触发死锁或半提交。
实操建议：
- 放弃双主写入，严格按“一主多从+读写分离”设计，Keepalived只用于主库故障时切换主角色
- 如果真要双主，务必启用
gtid_mode=ON+enforce_gtid_consistency=ON，并用mysqlfailover或orchestrator替代Keepalived - 所有写操作必须走同一入口（比如ProxySQL），由中间件判断主节点状态，而不是靠VIP硬切
- 测试时用
tcpdump -i any port 3306抓包，确认写请求确实只打到当前主库，没因DNS缓存或连接池残留打到旧主
Keepalived的配置再简洁，也掩盖不了MySQL主从状态不可靠的事实。线上切主前，先看Seconds_Behind_Master，再看SHOW PROCESSLIST里有没有长事务堵着SQL线程——这些比systemctl restart keepalived重要得多。
