VIP切换必须与数据库角色变更严格同步，否则必然导致脑裂或连接中断；核心是VIP归属由数据库真实状态（如read_only、复制延迟等）决定，而非仅依赖Keepalived进程或端口检测。
直接说结论：VIP切换不是“绑上就完事”，它必须和数据库角色变更严格同步，否则必然出现脑裂或连接中断。核心在于“谁有资格拿VIP”得由数据库状态说了算，而不是网络层自己拍板。
为什么不能只靠Keepalived自动抢VIP
Keepalived默认只检测本机MySQL进程存活（pidof mysqld）或端口连通性（nc -z 127.0.0.1 3306），但这两项完全无法反映真实数据库角色：
- 主库MySQL进程还在，但复制线程卡死、
Seconds_Behind_Master持续上涨，此时它已不适合继续提供写服务 - 从库MySQL进程正常，但
Slave_IO_Running和Slave_SQL_Running都是No，它根本没数据，却可能被Keepalived误判为可用而抢走VIP - 云环境或容器中，
arping广播可能被拦截，导致VIP漂移后客户端收不到ARP响应，连接持续超时
切换脚本里必须校验的数据库状态项
任何VIP切换动作前，至少要确认以下三项全部通过，缺一不可：
-
SELECT 1能连通且返回成功（排除网络/防火墙问题） -
SHOW GLOBAL VARIABLES LIKE 'read_only'返回OFF（确认当前节点允许写入） -
SHOW SLAVE STATUS\G中：Slave_IO_Running: Yes、Slave_SQL_Running: Yes、Seconds_Behind_Master: 0（仅对候选新主有效；若当前是主库，则此项应跳过）
注意：Seconds_Behind_Master 为 NULL 表示复制未启动，0 才代表已追平——很多脚本只检查非空，这是坑。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
arpping 和 ifconfig 的执行顺序不能颠倒
VIP绑定后立刻发arping是防止脑裂的关键动作，但必须在ifconfig或ip addr add之后、应用开始连接之前完成：
- 错误顺序：
ip addr add VIP→ 应用尝试连接 →arping -U（此时客户端可能已建立TCP连接但卡在握手，后续请求全失败） - 正确顺序：
ip addr add VIP→arping -q -c 2 -U -I eth0 VIP→ 等待1秒 → 开放应用访问 - 云厂商如阿里云/腾讯云不支持
arping，需改用云平台API触发ARP刷新（例如调用ecs.AssociateEipAddress）
Orchestrator Hook里VIP迁移的典型陷阱
用Orchestrator做高可用时，Hook脚本常犯两个硬伤：
- 在
post-master-failover阶段直接执行ip addr add，但此时新主可能还没执行SET GLOBAL read_only=OFF，VIP绑上去也接不住写请求 - 没检查
MasterFailoverDetachReplicaMasterHost是否设为true，导致旧主恢复后自动重连新主，形成双主冲突，VIP反而成了放大器 - Hook脚本用
ssh user@host "ip addr add..."，但SSH连接超时未设-o ConnectTimeout=5，一旦目标机负载高，整个切换流程卡死
真正可靠的切换，永远是数据库状态驱动网络动作，而不是反过来。多一次SHOW SLAVE STATUS查询，比少一次arping安全得多。
