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 才代表已追平——很多脚本只检查非空，这是坑。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

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安全得多。