Keepalived 不提供负载均衡，仅通过 VIP 漂移实现高可用；真正读写分离需 ProxySQL/HAProxy 等代理层，Keepalived 仅保障其入口 IP 永在线。
MySQL 本身不支持负载均衡，得靠外围组件分发请求
MySQL 单实例天然不具备读写分离或流量分发能力。所谓“MySQL 负载均衡”，实际是把连接请求分给多个 MySQL 实例（比如一主多从），由外部工具完成路由决策。Keepalived 并不参与 SQL 路由——它只管 VIP（虚拟 IP）漂移，解决的是**高可用（HA）故障切换**问题，不是负载均衡。真要做读写分离+负载均衡，得配 ProxySQL、MaxScale 或 HAProxy；Keepalived 只负责让这个代理（或主库）的入口 IP 永远在线。
Keepalived 配置 VIP 的核心逻辑：谁抢到谁说话
Keepalived 通过 VRRP 协议让多台机器竞争一个 virtual_ipaddress。主节点健康时，VIP 绑定在它身上；一旦 check_script 检测到 MySQL 停了（比如 systemctl is-active mysqld 返回非 active），就降权退出，备节点升权接管 VIP。这不是“均衡”，是“热备”。
- 必须写自定义检测脚本，不能只依赖进程存在——MySQL 进程可能活着但拒绝连接
-
vrrp_script中建议用mysql -h127.0.0.1 -P3306 -e "SELECT 1"真连一次，超时加-o Connect_timeout=3 -
priority值差至少 50，避免脑裂；advert_int设为 1 秒，加快故障感知 - 所有节点的
virtual_router_id必须相同，且在同一二层网络（跨 VLAN 需调优组播）
Keepalived + MySQL 主从切换时，应用会断连吗
会。VIP 漂移本身很快（秒级），但 TCP 连接不会自动迁移——旧连接仍指向原主机，新连接才打到新 VIP 所在机器。如果主库挂了，而 Keepalived 把 VIP 切到从库，但该从库没开 read_only=OFF 或没提权为可写，应用执行 INSERT 就直接报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 切换前必须确保备节点已执行
STOP SLAVE; RESET SLAVE ALL;并关闭read_only - 应用层要有重试机制，不能假设一次连接永久有效
- 不要用
autocommit=0长事务跨切换——事务状态不会同步过去 - 检查
max_connections是否足够，VIP 漂移后所有流量涌向单点，容易打满
为什么别把 Keepalived 直接连应用，绕过代理层
因为 VIP 只解决“找哪台机器”的问题，不解决“该发什么请求过去”。比如你用 Keepalived 把 VIP 绑到主库，应用直连 VIP 写入；一旦切换，VIP 跳到从库，所有写请求立刻失败——除非你手动改从库配置，但这违背自动化初衷。
- 正确姿势是 VIP 绑在
ProxySQL或HAProxy实例前，由它们做读写分离和健康检查 -
Keepalived只保障代理服务本身的高可用，不是数据库的 - 若硬要 VIP 直连 MySQL，必须配合 MHA 或 Orchestrator 做自动主从提升，且严格校验复制延迟（
Seconds_Behind_Master
真正麻烦的从来不是配置几行 vrrp_script，而是确认主从数据一致、权限同步、慢查询不卡死 IO、以及应用能否安静接受连接中断——这些没法靠 keepalived.conf 一行命令兜底。
