Keepalived仅负责VIP漂移，MySQL主从复制必须先正常运行且延迟≤1秒、binlog_format=ROW、server-id唯一、CHANGE MASTER参数准确；健康检查需用vrrp_script同时验证MySQL进程与复制状态，weight设为-5以下，track_script不可遗漏；须配置ip_nonlocal_bind=1、放行VRRP协议、MySQL bind-address包含VIP；建议BACKUP节点启用nopreempt并降低priority，避免自动抢VIP导致双写。

Keepalived 本身不负责数据库同步，只管 VIP 漂移；MySQL 主从双机热备必须先跑通复制，否则 Keepalived 切过去就是个空壳——这是最常被忽略的前提。

---

MySQL 主从复制必须先验证正常运行

Keepalived 的健康检查脚本再完善，也救不了一个已经断掉的复制链路。生产中 70% 的“VIP 切了但查不到数据”问题，根源都在这里。

• SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 必须同时为 Yes
• Seconds_Behind_Master 应稳定为 0（或极小值，如 ≤1），持续非零说明主从延迟严重
• 主库 binlog_format 必须设为 ROW（MySQL 5.7 默认是 STATEMENT，不满足一致性要求）
• 主从 server-id 必须全局唯一，且重启 mysqld 后用 SELECT @@server_id; 确认生效
• 从库执行 CHANGE MASTER TO 时，MASTER_LOG_FILE 和 MASTER_LOG_POS 必须来自主库当前 SHOW MASTER STATUS 输出，不能复用旧快照

---

Keepalived 配置里最关键的三项参数

Keepalived 默认只检测自身进程，对 MySQL 状态完全无感。必须通过 vrrp_script 显式绑定检测逻辑，并在 vrrp_instance 中引用。

win可用的mysql指令skill

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

下载

• vrrp_script chk_mysql 必须同时检查两个维度：
  • MySQL 进程存活：pgrep mysqld > /dev/null
  • 复制状态正常：mysql -Nse "SELECT Slave_IO_Running, Slave_SQL_Running FROM information_schema.PROCESSLIST LIMIT 0" 2>/dev/null | grep -q "Yes.*Yes"（更稳妥的做法是直接查 SHOW SLAVE STATUS 输出）
• weight 建议设为 -5 或更低，确保检测失败时优先级足够低、能触发切换
• track_script 块中必须明确写入脚本名，例如：track_script { chk_mysql }，漏掉这行等于没写检测

---

防火墙和内核参数不放开，VIP 根本绑不上

即使配置全对，ip addr show 里也看不到 VIP，常见于以下三个硬性限制：

• net.ipv4.ip_nonlocal_bind = 1 必须写入 /etc/sysctl.conf 并执行 sysctl -p 生效，否则 Keepalived 无法绑定非本机 IP
• 防火墙需放行 VRRP 协议（协议号 112）：
  iptables -I INPUT -p vrrp -j ACCEPT（CentOS 7+ 若用 firewalld，则用 firewall-cmd --add-protocol=vrrp --permanent）
• bind_address 在 MySQL 配置中必须包含 VIP 所在网卡，例如：bind-address = 0.0.0.0 或显式列出 192.168.1.65 和 192.168.1.100，否则应用连不上 VIP

---

非抢占模式比默认抢占更稳

默认情况下，原 MASTER 恢复后会立即抢回 VIP，但此时 MySQL 可能尚未完成复制追平，或应用连接还没清理干净，容易引发短暂双写或连接混乱。

• 在 vrrp_instance VI_1 块中加 nopreempt（仅 BACKUP 节点配置，MASTER 节点不要加）
• 同时把 BACKUP 节点的 priority 设得略低于 MASTER（如 MASTER=100，BACKUP=98），避免意外选举颠倒
• 故障恢复后，需人工确认 SHOW SLAVE STATUS\G 已同步完成，再酌情手动触发 VIP 回切（如 systemctl restart keepalived）

真正麻烦的从来不是配置本身，而是复制延迟未被感知、VIP 绑定被内核拦截、或者故障恢复后自动抢回却没等同步追平——这些点不盯住，高可用就变成高风险。