keepalived在私有云中实现mysql高可用的核心前提是网络层放行vrrp（协议号112）报文；若被拦截，必须改用unicast_peer单播模式，并配置双主自增偏移与强制arp刷新以确保vip漂移生效且数据一致。
Keepalived 在私有云环境里跑 MySQL 高可用，核心不是“能不能用”，而是虚拟网络层是否允许 VRRP 协议报文自由收发。多数私有云（如 OpenStack、VMware vSphere、华为云 Stack、阿里云专有云）默认会拦截或限制 VRRP（协议号 112）的组播/广播包，直接套用物理机配置大概率 VIP 不漂移、状态卡在 BACKUP 或反复切换。
下面分三块说清关键动作：
确认私有云是否放行 VRRP 流量
这是第一步，也是最容易被跳过的致命环节。别急着写 keepalived.conf，先验证底层网络是否支持：
- 查文档：翻你所用私有云平台的“安全组规则”“网络 ACL”“分布式防火墙”章节，确认是否明确支持协议号
112（VRRP）； - 实测：在两台 MySQL 节点上分别执行
tcpdump -i eth0 ip proto 112，然后手动systemctl restart keepalived，看能否抓到对方发来的 VRRP Advertisement 报文； - 若抓不到且无报错，基本可判定被网络设备静默丢弃 —— 此时必须切换为单播模式，不能硬扛。
强制使用 unicast_peer 模式（私有云唯一可靠路径）
组播失效时，vrrp_instance 必须显式配置对端 IP，否则节点间无法协商主备。CentOS/RHEL 系统下，/etc/keepalived/keepalived.conf 中关键段要这样写：
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
unicast_src_ip 192.168.5.161 # 当前节点真实 IP
unicast_peer {
192.168.5.162 # 对端节点真实 IP
}
virtual_ipaddress {
192.168.5.200/24 # VIP，掩码需与网段一致
}
track_script {
chk_mysql
}
}
注意：state 两边都设 BACKUP，靠 priority 决定谁先抢 VIP；unicast_src_ip 和 unicast_peer 必须是能直连的内网地址，不能是 VIP 或 NAT 后地址。
MySQL 双主同步必须规避自增冲突
私有云不改变 MySQL 数据一致性逻辑。双主写入下，auto_increment 若不做隔离，必然主键冲突导致复制中断。必须在两节点 my.cnf 中配对设置：
- 节点 A：
auto-increment-increment = 2，auto-increment-offset = 1； - 节点 B：
auto-increment-increment = 2，auto-increment-offset = 2； - 重启 MySQL 后，执行
SHOW VARIABLES LIKE 'auto_inc%'确认生效； - 禁止应用层显式指定自增字段值（如
INSERT INTO t(id, name) VALUES(100, 'x')），否则仍可能撞。
私有云里最常被忽略的其实是 ARP 刷新机制 —— garp_master_delay 和 garp_master_refresh 这两个参数在部分云平台驱动下不生效，导致下游服务器缓存旧 MAC，VIP 漂过去后流量仍发往原节点。建议在 VIP 绑定脚本里加一行 arping -c 3 -A -I eth0 192.168.5.200 强刷。
