5分钟搞定MySQL高可用：Keepalived+VIP漂移实战指南

做运维这几年，MySQL的高可用方案我前后试过不少，主从加手工切换、MHA、Orchestrator，再到K8s里的Operator，各有各的适用场景。但要论“最快让业务拥有一个虚IP、并且故障时能自动漂移”的性价比方案，Keepalived绝对是绕不开的一个。标题里说5分钟，咱不能真掐表，但把配置核心思路理顺之后，Keepalived相关的配置半小时内搞定是真能做到的。这篇文章就从方案选型、环境准备、配置细节到故障实测，完整走一遍，照着做就能跑起来。

1. 整体方案设计与选型思路

1.1 这个方案到底解决了什么问题

先捋一下业务痛点。通常一个MySQL实例挂在某台服务器上，客户端连接用的是这台机器的内网IP。一旦这台机器出现宕机、网络异常、MySQL进程崩溃，客户端就连不上了，只能等人工介入处理。哪怕你做了主从复制，备库数据是完整的，也得手动把连接切到备库去，这个过程少则几分钟，多则半小时，业务影响不小。

Keepalived这套方案的核心，就是引入一个“虚IP”（VIP，Virtual IP），客户端不再直连物理IP，而是连VIP。Keepalived在主备两台机器上各自运行，通过VRRP协议协商谁持有VIP。正常情况下Master持有VIP并提供服务，Backup默默待命；一旦Master故障、MySQL异常，VIP会自动“漂移”到Backup上，客户端重连（或者连接池自动重连）就能继续访问，几乎感知不到后端发生了什么。

这套方案适合什么场景呢？我个人的判断是：中小型团队、预算有限的内部系统、对数据一致性要求不算苛刻（可以接受主从延迟）的读写业务、以及DBA人力并不充裕的团队。它不是万能的，和MHA、Orchestrator这类专职数据库高可用组件相比，Keepalived本身并不感知MySQL数据同步状态，它只做“IP漂移”这一件事。但它简单、直接、可控，尤其对于“尽快恢复服务”这个目标来说，非常够用。

1.2 为什么在众多方案里选Keepalived

说实话，MySQL高可用方案现在选择非常多。MHA是Perl写的经典方案，能做故障检测、日志补偿、自动提升主库，但代码多年不怎么更新，对新版本MySQL的兼容性、半同步复制的配合都稍显吃力。Orchestrator基于Raft做元数据管理，功能强大，但部署和运维心智成本偏高，还需要额外的后端存储。数据库中间件（ProxySQL、MyCat、ShardingSphere）也能做读写分离和故障转移，但把负载均衡和实际存储层的高可用混在一起，排障链路会变长。

Keepalived的优势恰恰是它足够“笨”。它只负责一件事：用VRRP协议选出一个Master，让VIP始终绑定在Master上，Master挂了就换一个。这种设计看起来简单，但生产环境里往往越简单的方案越稳定。加上它不侵入MySQL本身，不需要改数据库配置，不需要引入额外的代理节点，资源占用极低（一个VRRP实例只跑几个进程，内存占用几MB），多台机器之间只用一条UDP组播或单播报文互相确认存活，网络开销可以忽略。

所以我的选型结论是：如果你的MySQL已经做好了主从（或者双主），只是缺一个自动切换入口，那直接用Keepalived是最省事的。它不解决“MySQL主从数据落后”的问题，那是复制策略的事；它解决的是“故障发生后能不能快速恢复对外服务”的问题。把这两个问题分开思考，方案边界就非常清晰了。

2. 环境准备与基础搭建

2.1 服务器规划和角色划分

动手之前先把环境定清楚。以下是我在测试和生产中都验证过的标准形态：

操作系统选用CentOS 7.9或者Rocky Linux 8/9都行，测试环境可以是虚拟机，生产建议物理机或云主机均无问题。MySQL版本我这里用的是8.0.36，其实5.7和8.0在Keepalived配合上没有本质区别。

这里要说一个规划上的重要细节：MySQL的主从复制关系和Keepalived的主备角色，在初始部署时建议保持一致，也就是db01既是复制主库也是Keepalived的MASTER，db02既是从库也是BACKUP。但Keepalived的MASTER和BACKUP只是一个“竞选初始优先级”的概念，它不影响MySQL复制拓扑本身。后面如果发生了VIP漂移，db02变成了对外提供服务的节点，那么理想情况下应该把db01恢复后的复制关系反向调优为“新主旧备”，让db01变为从库，避免两个库同时写。

为了简化运维，我在生产环境其实更推荐双主模式（互为主从），这样VIP无论漂移到哪一台，该节点都是可写状态，不会出现从库只读导致业务写失败的情况。配合auto_increment_offset和auto_increment_increment的设置避免自增主键冲突，双主写成两行配置就搞定了。当然双主也有双写的隐患，比如同时在两边修改同一条数据，会引发复制冲突，需要在应用侧做好路由约束。我这里演示用的是双主结构，简单直接，你们可以根据自己业务情况选择。

2.2 MySQL安装与双主复制配置

MySQL的安装不是本文重点，但双主复制我会简短讲一下关键参数。如果机器上还没装MySQL，建议直接用官方Yum仓库装：

# 安装MySQL官方Yum仓库 yum install -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm # 安装MySQL社区版 yum install -y mysql-community-server # 启动并设置开机自启 systemctl enable mysqld --now

安装完成后，编辑/etc/my.cnf，在[mysqld]段下配置双主所需的核心参数。db01和db02的配置大体相同，唯一不同的是server-id：

[mysqld] server-id=1 log-bin=mysql-bin binlog_format=ROW gtid_mode=ON enforce_gtid_consistency=ON log_slave_updates=ON skip_name_resolve=ON max_connections=500 # 双主防自增冲突 auto_increment_offset=1 auto_increment_increment=2 # 默认开启只读，避免双写冲突（双主场景按需关闭） read_only=OFF

db02把server-id改成2，auto_increment_offset改成2即可。这里稍微解释一下这几个参数的意义：log_slave_updates=ON是为了让从库把“从主库同步来的变更”也写进自己的binlog，这样互为从库时才能继续转发变更；gtid_mode=ON是启用GTID复制，简化主从切换后的链路重建；auto_increment_offset/increment是为了两台机器自增ID不撞车。这几个参数在生产MySQL架构里几乎是标配，建议直接抄。

然后分别在两台机器上创建复制账号，并构建复制链路。先在db01上执行：

-- 创建复制账号 CREATE USER 'repl'@'10.0.0.%' IDENTIFIED BY 'YourStrongPassword'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'10.0.0.%'; FLUSH PRIVILEGES;

db02上同样创建账号（db01连接db02也要用），然后两边互指：

-- 在db01上执行，指向db02 CHANGE MASTER TO MASTER_HOST='10.0.0.12', MASTER_USER='repl', MASTER_PASSWORD='YourStrongPassword', MASTER_AUTO_POSITION=1; START SLAVE; -- 在db02上执行，指向db01 CHANGE MASTER TO MASTER_HOST='10.0.0.11', MASTER_USER='repl', MASTER_PASSWORD='YourStrongPassword', MASTER_AUTO_POSITION=1; START SLAVE;

查看复制状态确认Slave_IO_Running: Yes和Slave_SQL_Running: Yes，双主复制就通了。这里要注意，如果两台机器是全新初始化的MySQL，直接GTID互指没问题；如果是已经有业务的库，需要先备份再恢复，确保GTID集合一致后再搭复制，不然报错会很烦躁。

2.3 Keepalived安装前的系统准备

Keepalived的安装很简单，各发行版都有现成的包：

# CentOS/Rocky yum install -y keepalived # Ubuntu/Debian apt install -y keepalived

但安装之前有几项系统层面的准备工作不能跳过。首先是防火墙，VRRP协议默认走IP协议号112（组播地址224.0.0.18），如果机器上开着firewalld或iptables，一定要放行。CentOS 7/8下面这样操作：

# firewalld放行VRRP firewall-cmd --permanent --add-rich-rule='rule protocol value="112" accept' firewall-cmd --reload

如果你不习惯用组播，Keepalived也支持单播模式（后面配置里会讲），防火墙只需要放行主机之间的单播通信端口即可。我建议机房内网环境直接用单播，更安全也更可控。

其次是关闭可能干扰VIP绑定的NetworkManager对网卡的接管，以及保证rp_filter（反向路径过滤）不会误伤VIP的入流量。生产上如果发现VIP能漂过去但外部访问不通，多半和rp_filter有关。在/etc/sysctl.conf里确认：

net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0

执行sysctl -p使其生效。这一步很容易被忽略，但它恰恰是很多“VIP漂移后连不上”案例的根因。

3. Keepalived配置逐行拆解

3.1 vrrp_instance与全局配置的要点

Keepalived的配置文件默认在/etc/keepalived/keepalived.conf。初次打开这个文件，你会发现它主要由三块组成：global_defs（全局定义）、vrrp_instance（VRRP实例）、vrrp_script（健康检查脚本）。MySQL高可用场景下，真正核心的是vrrp_script和vrrp_instance的配合。

这里先给一份我实测可用的Master配置，然后逐段解释：

global_defs { router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0 } vrrp_script check_mysql { script "/etc/keepalived/check_mysql.sh" interval 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 nopreempt unicast_src_ip 10.0.0.11 unicast_peer { 10.0.0.12 } authentication { auth_type PASS auth_pass 123456 } track_script { check_mysql } virtual_ipaddress { 10.0.0.100/24 dev eth0 label eth0:1 } notify_master "/etc/keepalived/notify.sh MASTER" notify_backup "/etc/keepalived/notify.sh BACKUP" notify_fault "/etc/keepalived/notify.sh FAULT" }

把配置文件读完，你会发现Keepalived的工作逻辑非常直白。global_defs里最常见的坑是vrrp_strict这个选项。它开启之后，Keepalived会强制使用VRRP协议规则，比如不允许VIP地址和本机IP在同一网段之外绑定，甚至会拦截非VRRP的报文。如果只是想快速做IP漂移，我一般建议先注释掉vrrp_strict，等生产环境网络策略都捋清楚之后再加上，否则很容易出现“VIP明明在，但就是不通”的诡异问题。

vrrp_script是MySQL健康检查的入口，它定义了一个可调用的脚本，并指定了执行周期和判定规则。interval 2表示每2秒执行一次脚本；fall 2表示连续失败2次才判定节点故障；rise 2表示连续成功2次才判定节点恢复。这几个参数直接决定了故障转移的灵敏度。测试环境我觉得可以激进一点，interval 1、fall 2，总耗时2秒左右；生产环境我建议interval 2、fall 3，总耗时6秒，稍微保守一些，以免网络抖动引发不必要的切换。

3.2 健康检查脚本的编写，别只检查进程

健康检查脚本是整个方案里最容易被写坏的地方。很多人图省事，脚本里只写一句pgrep mysqld，只要MySQL进程在，就认为数据库是健康的。问题是进程在，不代表数据库能正常接受连接。我曾经遇到过MySQL进入假死状态（进程在，但端口不响应、连接卡死）的情况，这时候如果不做“真实验证”，Keepalived会认为一切正常，VIP自然不会漂移，业务照样不可用。

我这边维护的检查脚本，至少会做三件事：检查进程、检查端口、实际执行一条SQL验证可读写。

#!/bin/bash # /etc/keepalived/check_mysql.sh MYSQL_HOST="127.0.0.1" MYSQL_PORT="3306" MYSQL_USER="keepalived" MYSQL_PASSWORD="YourCheckPassword" # 1. 检查进程是否存在 if ! pgrep -x mysqld > /dev/null 2>&1; then echo "MySQL process not found" exit 1 fi # 2. 检查端口是否LISTEN if ! ss -lnt | grep -q "0.0.0.0:${MYSQL_PORT}"; then echo "MySQL port ${MYSQL_PORT} not listening" exit 1 fi # 3. 实际执行SQL验证可读写 if ! mysql -h"${MYSQL_HOST}" -P"${MYSQL_PORT}" -u"${MYSQL_USER}" -p"${MYSQL_PASSWORD}" \ -e "SELECT 1" > /dev/null 2>&1; then echo "MySQL query failed" exit 1 fi exit 0

注意两点：一是脚本执行账号要能被Keepalived调用且具备执行权限，建议chmod +x /etc/keepalived/check_mysql.sh；二是MySQL里需要创建对应的检测账号，并且只给只读权限，不要用root当检测账号。我习惯创建一个专用账号：

CREATE USER 'keepalived'@'127.0.0.1' IDENTIFIED BY 'YourCheckPassword'; GRANT SELECT ON *.* TO 'keepalived'@'127.0.0.1'; FLUSH PRIVILEGES;

有同学可能会问，为什么要用127.0.0.1而不直接用socket连接？因为socket连接只能证明本地进程存在，用TCP连接可以顺便验证监听地址和端口是否对外正常，更贴近真实故障场景。还有一点，脚本返回非0时Keepalived会认为当前节点不健康，从而降低优先级并释放VIP，所以在脚本末尾务必用明确的exit 0/exit 1来表达结果。

3.3 MASTER和BACKUP配置的差异与关键行

对比Master配置，Backup的配置只需要改动几个地方：

virtual_router_id必须两边一致，这是VRRP分组识别的依据，两台机器之间就是通过它来相互感知的。priority相差10即可，不能两边设成一样的值，否则会出现抢VIP的抖动。

关于nopreempt，这里有个很容易踩的坑。默认情况下，如果Backup（优先级低）在Master故障时接管了VIP，等原Master恢复并重新加入VRRP组后，它会因为优先级更高而强行抢回VIP，这叫做“抢占模式”。对外表现就是VIP在两个节点间来回跳一次，连接会瞬间中断。对于数据库这种长连接应用，这种回切抖动很烦。所以我建议在Master配置中加上nopreempt，让整个集群变成“非抢占模式”。

设置了nopreempt之后，原Master恢复时不会主动抢回VIP，VIP会一直停留在接管节点，直到下次故障或者人工介入。这在大多数场景下是合理的，因为业务的连续优先于“让主库回到原来那台机器”。不过要注意，nopreempt只在state MASTER的节点上设置才生效，两边都要写。如果你确实需要原Master恢复后自动回切，就删掉这个选项，并把两边节点的state都配置成BACKUP（这样只通过priority比较），但切换时的抖动要做好心理准备。

3.4 虚IP漂移的原理和优先级计算逻辑

虚IP漂移这件事，很多人用得很熟，但真要问“它为什么能漂”，能讲清楚的人不多。其实核心就是VRRP协议（Virtual Router Redundancy Protocol，虚拟路由冗余协议）。Keepalived启动后会向组播地址224.0.0.18发送VRRP报文，报文中包含当前节点的优先级和路由器ID。优先级高的节点会周期性通告自己“我还活着”，优先级低的节点收到通告后，知道自己不是Master，就默默等待。

MySQL故障时，track_script检测到脚本退出码非0，Keepalived会把该节点的优先级调低（或者直接进入FAULT状态），同时停止发送VRRP通告。Backup在连续几个advert_int周期内收不到Master的通告，就认为Master挂了，然后抢占成为新的Master，在本机绑定VIP，并向外发送免费ARP（Gratuitous ARP），告诉交换机“这个IP的MAC地址变了”，流量自然就引到新机器上。

这一步是“先释放VIP再绑定VIP”的过程，中间会有极短暂的时间窗口内VIP不在任何节点上。所以客户端如果用的是连接池，要设置合适的连接超时时间，保证断开的连接能快速重建，而不是一直卡在旧连接上重试。通常这个窗口在1~3秒之间，配置合理的话，对业务的影响很小。

4. 实操验证：让VIP真正漂移一次

4.1 初始状态确认与验证方法

配置都写完，两台机器上启动Keepalived，第一件事是确认初始状态：

# 查看Keepalived日志 tail -f /var/log/messages # 查看VIP绑定状态 ip addr show eth0

正常情况下，db01（MASTER）上能看到eth0:1绑定着 10.0.0.100，db02（BACKUP）上没有VIP地址。再用ip neigh或者抓包工具确认VRRP报文在正常收发：

# 在db01上开启抓包，观察VRRP报文 tcpdump -i eth0 -n vrrp

如果一直有vrrp: Coming up之类的输出，说明协议通信正常。这时候从任意一台业务机器上ping 10.0.0.100，应该能通，并且响应来自db01。

切换到db02上做同样的检查，BACKUP节点的日志里应该能看到enter BACKUP state等字样，但不会绑定VIP。这一步确认OK，基础的初始状态就对了。

4.2 模拟Master故障，观察VIP切换

为了验证漂移效果，最直接的办法是让db01的mysqld进程直接“假死”：

# 在db01上执行 systemctl stop mysqld

然后观察两个节点和VIP的变化。清空db01和db02上的Keepalived日志，方便记录切换时间点。16:00:00执行systemctl stop mysqld后，db01上的check_mysql.sh会在2秒左右检测到MySQL不可用，继续失败1次后（fall 2），Keepalived在16:00:05左右把db01置为FAULT状态，VIP从db01上解绑。db02在1秒内没收到db01的VRRP通告，加上自己的检查脚本确认本机MySQL正常，随即提升为MASTER，绑上10.0.0.100，并在网卡上发出免费ARP广播。

整个过程我在实际测试中耗时大概在4~6秒之间。用手机秒表能感知到大概“断了5秒网”，对一般业务来说可接受，但如果你的业务对中断极其敏感，可以通过调小interval和fall来提速，不过要承担误判的风险。

4.3 Recovery：恢复Master后的行为与配置经验

Master恢复的测试同样重要。在db01上把MySQL拉起来：

systemctl start mysqld

这时候MySQL从库会自动追上db02的binlog（双主配置下），Keepalived恢复心跳。由于我在配置里加了nopreempt，db01即使状态恢复，优先级更高也不会抢回VIP，VIP继续留在db02上。这在生产环境是我推荐的做法，原因前面说过了，避免VIP来回抖。但要注意，这意味着长期来看db02是实际对外提供服务的主库，db01变成它的从库，业务访问入口并没有切回到原主库。如果需要回切，操作步骤是：先停掉db02上的Keepalived，让VIP自动漂回db01，再启动db02的Keepalived，让它继续当BACKUP。这样回切是平滑的，不会出现两边同时持有VIP的脑裂。

我见过不少同学忽略了这个“非抢占”和“回切”的关系，生产上出现“明明主库已经修好了，VIP怎么还在备机上”的困惑，其实这不是故障，而是nopreempt的预期行为。所以配置前就想清楚：你是要“自动回切”还是“保持当前可用节点不抖动”，这两者在Keepalived里天生是互斥的。

5. 常见问题与排查技巧实录

5.1 常见问题排查速查表

我把实操中遇到的问题整理成一张速查表，覆盖了90%以上的故障场景，照着顺序排查，基本上都能定位：

5.2 通知脚本与监控平台联动

VIP漂移发生了，如果运维同学完全不知道，那这“高可用”就打了折扣。Keepalived提供了notify_master、notify_backup、notify_fault三个钩子，分别在节点状态变化时触发脚本，很适合接告警通知。我写了一个简单的通知脚本，状态切换时发一条消息到企业微信/钉钉机器人：

#!/bin/bash # /etc/keepalived/notify.sh TYPE=$1 IP=$(ip addr show eth0 | grep 'inet ' | awk '{print $2}') case $TYPE in MASTER) MESSAGE="MySQL高可用: $(hostname) 成为MASTER，VIP绑定中。本机IP: ${IP}" ;; BACKUP) MESSAGE="MySQL高可用: $(hostname) 转为BACKUP，待命中。本机IP: ${IP}" ;; FAULT) MESSAGE="MySQL高可用: $(hostname) 进入FAULT状态，请立即检查！本机IP: ${IP}" ;; *) exit 0 ;; esac # 这里替换成你的webhook地址 curl -s -X POST 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY' \ -H 'Content-Type: application/json' \ -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"${MESSAGE}\"}}"

脚本记得加执行权限，并在Keepalived配置文件中通过notify_master、notify_backup、notify_fault引用它。这样一旦发生过切换，运维能第一时间收到告警，随后去检查原主库的故障原因，而不是被业务侧“数据库怎么卡了一下”的反馈被动搅得焦头烂额。

5.3 脑裂问题的现实处理与防范

提到Keepalived和MySQL高可用，必然绕不开“脑裂”这个词。所谓脑裂，就是主备两台节点都认为自己是唯一活跃的Master，都试图提供服务、都持有VIP，造成业务写入分裂到两个MySQL实例上，双主场景下数据一致性会被破坏。

现实情况是，MySQL高可用的“脑裂”不完全等同于网络分区，常见诱因有两个：一是VRRP通信中断（网络抖动/防火墙拦截），二是健康检查脚本在两边都判定失败。第一个情况就是两台机器网络不通，但各自MySQL都正常，于是各自抢占VIP；第二个情况比较隐蔽，比如脚本里用的MySQL密码过期了，两边都检查失败，两个节点都进入FAULT状态，VIP反而没人持有。

我的应对方法是三层防护。第一，VRRP层面优先使用unicast_peer单播通信，明确指定对端IP，避免组播在复杂网络中的不确定性。第二，Keepalived检测与MySQL健康状态强绑定，并且加上冗余检查项，不只依赖一个脚本。第三，应用层连接必须走VIP，但连接池要配置“读写分离”路由策略，确保即使出现了极端脑裂，写入也只打到持有VIP的节点，降低数据损坏概率。

当然，最稳妥的兜底是数据文件与binlog的定期备份。Keepalived的漂移只是减少RTO，绝不能替代备份体系。这一点无论方案多完善，都不能省。

6. 这个方案的天花板与扩展路径

再回过头来说说影响范围。Keepalived+MySQL这套方案能覆盖很大一部分场景，但也有明显边界。它不感知MySQL复制延迟，切换时如果主从延迟过大，会丢最近的写入；它对双写冲突没有防护能力；它无法像专门的HA组件那样提供“半同步复制”的联动保障。

那什么场景下需要升级？如果业务对数据一致性要求更高，比如金融交易类系统，建议考虑MySQL半同步复制配合MHA或者Orchestrator；如果团队已经有K8s环境，直接用Operator管理MySQL实例把故障转移交给控制器会更省心；如果只是读多写少的内部工具，这套Keepalived方案足够用很久。

我个人经历里，用Keepalived支撑过多个日均几十万请求的内部系统，最长稳定运行超过两年，期间发生过几次物理机维护和一次硬件故障，VIP漂移都能达到预期效果。这套办法的适用性和稳定性，是经过时间验证的。

最后给一个建议：如果你刚准备在生产环境上这个方案，先用模拟脚本频繁杀掉MySQL进程，多测几轮，确认漂移时间、回切行为、告警通知都符合预期，再切业务。做高可用，纸上谈兵没有用，必须真正打几场“演习”，后面真出故障时才不会慌。