keepalived 不能直接实现 mysql 主从高可用，因其仅负责 vip 漂移且不感知复制状态；必须先构建双主架构并配置自检脚本、合理参数及应用层连接池校验才能真正高可用。
Keepalived 不能直接让 MySQL 主从架构“高可用”，它只管 VIP 漂移；真要高可用，必须先做成双主（master-master），再用 Keepalived 绑定 VIP —— 否则主挂了，从不会自动变主，VIP 漂过去也没用。
为什么不能直接在主从上配 Keepalived
Keepalived 的 vrrp_instance 只检测本地服务存活或端口通断，它不理解 MySQL 复制状态。如果你把 VIP 绑在主库上、从库也配了 Keepalived 但设为 BACKUP，主库一挂，VIP 漂到从库——但此时从库的 Slave_IO_Running 和 Slave_SQL_Running 很可能早已停止，或者复制延迟几十秒甚至几分钟，直接切过去会丢数据、查不到最新写入。
常见错误现象：
- Keepalived 切换后应用连得上 VIP，但读不到刚写入的数据
- 切换后执行
SHOW SLAVE STATUS发现Seconds_Behind_Master是几百甚至几千 - 误以为“VIP 能通 = 数据就同步好了”，结果业务报主键冲突或唯一索引重复
双主 + Keepalived 的核心配置要点
双主不是简单互设 CHANGE MASTER TO 就完事，关键参数必须错开，否则并发写必然冲突：
-
server-id必须不同：一台设1，另一台设2 -
auto_increment_offset和auto_increment_increment要配对：比如都设auto_increment_increment = 2，一台设auto_increment_offset = 1，另一台设auto_increment_offset = 2 - 两台都必须开启
log-bin，且binlog_format建议用ROW（避免语句级复制在双主下出错） - 务必关闭
skip_slave_start（MySQL 5.7+ 默认已关），确保重启后复制线程自动拉起
示例片段（/etc/my.cnf）：
[mysqld] server-id = 1 log-bin = mysql-bin binlog-format = ROW auto_increment_offset = 1 auto_increment_increment = 2
Keepalived 配置里最容易漏掉的检测逻辑
默认的 TCP_CHECK 只连 3306 端口，MySQL 进程活着但复制卡死时，它照样认为“健康”。必须加自定义检查脚本，判断复制是否真正可用：
- 脚本需检查
Slave_IO_Running = Yes且Slave_SQL_Running = Yes - 最好再加
Seconds_Behind_Master （根据业务容忍度调整） - Keepalived 配置中用
notify_down触发脚本，并在vrrp_script块里调用该脚本作为健康判定依据 -
nopreempt必须设为yes，避免主库恢复后抢回 VIP 导致脑裂
典型错误配置：virtual_server 下只写 TCP_CHECK，没配 vrrp_script 或脚本返回值没被正确识别。
真实故障场景下最常被忽略的一点
即使双主 + Keepalived 全部配对、检测脚本也跑通，当主写节点宕机、VIP 漂移到备节点后，**应用连接池里的旧连接不会自动断开重连**。如果应用没做连接有效性校验（比如每次 query 前执行 PING 或简单 SELECT 1），就会继续往已失效的旧主库发请求，直到连接超时或池子回收——这期间的写操作全丢。
这不是 Keepalived 或 MySQL 的问题，而是应用层必须配合的点：连接池要启用 testOnBorrow 或等效机制，且测试 SQL 必须能暴露复制中断（例如查一个刚写入的表，或用 SELECT @@read_only 辅助判断角色）。否则整个高可用链路在最后一环就断了。
