MySQL 主从切换主库后，更新 VIP 漂移脚本的核心是修改健康检查逻辑指向新主库 IP，并强制旧主库释放 VIP。该方案适用于基于 Keepalived 或 Pacemaker 的高可用架构，主要风险在于切换瞬间可能出现双主 VIP 共存导致的脑裂。

命令速用版

以下命令用于检查当前 VIP 状态及重启高可用服务，操作前请确认当前节点角色。

# 查看当前网卡是否绑定 VIP
ip addr show | grep <VIP 地址>

# 重启 Keepalived 服务使配置生效
systemctl restart keepalived

# 手动移除 VIP（紧急止血用）
ip addr del <VIP 地址>/<掩码> dev <网卡名>

为什么会这样

VIP 漂移脚本的作用是解耦应用连接地址与物理服务器 IP，切换主库后必须移动 VIP 才能保证业务无感知。如果脚本未更新或执行失败，应用仍会连接旧主库，导致写入失败或数据不一致。高可用组件通常依赖健康检查脚本判断 MySQL 状态，主从角色变化后，脚本内的判断逻辑（如 read_only 变量）需与新主库状态匹配。

分步处理

按顺序执行以下步骤，确保 VIP 正确漂移到新主库，每一步完成后需确认状态再继续。

步骤 1：确认新主库就绪
登录新主库执行 SHOW MASTER STATUS;，确认同步延迟为零且可写入。备份旧主库上的 Keepalived 配置文件，通常位于 /etc/keepalived/keepalived.conf。

步骤 2：停止旧主库 VIP 服务
在旧主库节点停止 Keepalived 服务，防止脑裂。执行 systemctl stop keepalived，并运行 ip addr show 确认 VIP 已消失。若 VIP 未消失，使用 ip addr del 强制移除。

步骤 3：更新健康检查脚本
修改新主库节点上的检查脚本，确保逻辑判断 read_only=0 时持有 VIP。脚本需具备执行权限，命令示例：chmod +x /etc/keepalived/check_mysql.sh。若使用 MHA 或 Orchestrator，需同步更新其 hook 脚本中的 VIP 管理逻辑。

步骤 4：启动新主库 VIP 服务
在新主库节点启动 Keepalived 服务，执行 systemctl start keepalived。观察日志 /var/log/messages 或 journalctl -u keepalived，确认无报错且 VIP 添加成功。

怎么验证是否生效

通过网络连通性和数据库写入测试验证 VIP 是否正常工作。

1. 网络层验证
在应用服务器或网关执行 ping <VIP 地址>，确认通断正常。在新旧主库分别执行 ip addr show | grep <VIP 地址>，确保 VIP 仅存在于新主库。

2. 业务层验证
使用数据库客户端连接 VIP 地址，执行 SHOW VARIABLES LIKE 'read_only';，返回值应为 OFF。尝试执行一条写入语句，确认无报错。

常见坑

以下场景容易导致切换失败或数据风险，操作时需格外谨慎。

• 脑裂风险：若旧主库网络未完全断开且 Keepalived 未停止，可能出现双主同时持有 VIP。务必先停旧服务再启新服务。
• 脚本权限：健康检查脚本若无执行权限，Keepalived 会判定节点失败，导致 VIP 无法绑定。检查文件权限是否为 755。
• 网卡名称变化：不同服务器网卡名称可能不同（如 eth0 与 ens33），脚本中硬编码网卡名会导致 VIP 绑定失败。建议使用变量或自动识别。
• 复制延迟：切换前未确认主从同步完成，可能导致新主库数据缺失。切换前必须检查 Seconds_Behind_Master 为 0。

常见问题

切换主库后需要更新 DNS 记录吗？

不需要，VIP 机制本身就是为了避免修改 DNS 或应用配置。只要 VIP 漂移到新主库，应用连接地址无需变更。

如果切换失败如何回滚？

立即停止新主库的 Keepalived 服务，强制释放 VIP。在旧主库恢复 MySQL 写入权限，重新启动旧主库的 Keepalived 服务找回 VIP。

自定义脚本和 Keepalived 自带检查有什么区别？

自带检查仅监控进程存活，自定义脚本可检查 MySQL 读写状态。生产环境建议使用自定义脚本，避免只读节点持有 VIP。

参考来源

• Keepalived Official Documentation, Keepalived Configuration
• MySQL Documentation, Replication Solutions