MGR+KeepAlived生产级高可用落地：故障切换不再翻车

先说结论：MGR（MySQL Group Replication）加上KeepAlived这套组合，本身是能扛住生产环境节点故障的，但绝大多数团队第一次搭完，都会在“故障切换后业务连不上新主库”这个环节翻车。原因不是MGR不行，而是很多人把KeepAlived当成了一个单纯的“绑VIP”工具，没有让它在MGR的选主逻辑里真正找到“谁才是当前主库”。

这篇文章会从架构思路、环境准备、MGR搭建、KeepAlived配置、故障演练到排错速查，完整走一遍生产可用的落地流程。每一步都会解释为什么这么做，也会把我在实际环境里踩过的坑标出来。不管是第一次接触MGR的DBA，还是已经被MGR搞得焦头烂额的运维，按这个流程走下来，至少能少熬几个通宵。

1. 先想清楚：MGR + KeepAlived 这套组合到底在解决什么问题

1.1 MGR 与 KeepAlived 各自负责什么

MGR的核心能力是“组内数据一致”，它通过Paxos风格的共识协议，保证只要多数派节点存活，事务就不会丢。这个机制听起来很完美，但它有一个绕不开的短板——它不提供虚拟IP。也就是说，当主库节点宕机、MGR内部自动选出了新主库后，你的应用不会自动知道该连哪台机器了。

KeepAlived的价值就在于把这个“不知道该连谁”的问题解决掉。它就是为VIP（虚拟IP）漂移而生的，通过VRRP协议让一组节点共享一个IP，谁健康谁就持有这个IP对外提供服务。当主库节点宕机后，KeepAlived检测到异常，会让VIP漂移到新主库所在的那台机器上，业务通过VIP连接，完全无感知。

所以这两个组件并不冲突，而是天然互补：MGR负责数据库内部的数据一致和节点选主，KeepAlived负责对外网络的入口切换。

1.2 节点数量、网络与容灾模型怎么定

在生产环境里，最推荐的是三节点单主模式。原因非常简单，MGR需要多数派才能正常对外服务，三节点可以容忍一个节点故障，两个节点同时挂掉集群就只读了。如果只有两节点，任何一个节点故障都会导致集群无法形成多数派，这和一个节点没区别，还不如传统主从，所以两节点生产环境非常不建议。

三节点怎么放也很有讲究。如果三台都在同一个机柜、同一个交换机底下，整体故障风险其实并不低；如果分散在三个可用区，网络延迟和带宽又会直接影响写入性能。我的经验是：同城三机房间组MGR是性价比最高的方案，延迟通常能控制在1到3毫秒，故障隔离性也能满足大多数业务要求。跨城（比如北京和上海之间）做MGR就得慎重了，写事务的RT会明显增加，不是不能做，但业务方必须能接受这个延迟涨幅。

关于双机房加一个观察节点的方案，我不太建议新手尝试。虽然理论上可以通过调整参数实现，但组复制的多数派机制和网络分区时的行为会让排障变得极其复杂。生产环境求稳，三节点同城是最省心的起点。

2. 一个生产级 MGR 的环境到底需要准备到什么程度

2.1 主机规划与前置检查清单

我先列一下我习惯使用的主机规划模板，三台机器，角色清晰，后面所有命令里的IP都按这个来替换。

拿到机器后，不要急着装MySQL，先做以下几项检查，每一项都能排掉后面一个大坑。

时间同步必须提前搞定，MGR对节点间时钟偏差非常敏感，偏差太大会导致事务认证异常甚至节点被误踢。生产环境建议配置NTP或者chrony，并且确认时间同步服务是开机自启的。

防火墙只放行必要端口，MySQL默认的3306端口是业务端口，33061端口是MGR组内通信端口，KeepAlived的VRRP协议报文需要放行。如果用的是系统防火墙，需要确认这两条规则在每台机器上都生效。

hosts文件也很容易出问题。MGR节点之间通过hostname互相识别，如果主机名解析不到对方的IP，启动组复制的时候会直接报错。三个节点的/etc/hosts里都要写上三台机器的主机名和IP对应关系，不要只写其中一两台。

2.2 磁盘与数据目录规划

MySQL对磁盘性能的敏感度这里就不多说了，我这里想强调一个很多团队会忽略的点：redo log和binlog所在的磁盘，尽量不要和系统盘共用。生产环境一旦出现IO抢占，数据库性能会急剧恶化，而MGR本身又有额外的网络和共识开销，对磁盘的稳定延迟要求会比普通主从更高。

数据目录的规划建议单独划分一个数据盘，挂载到独立目录，比如/data/mysql。后面所有配置文件和初始化操作都基于这个路径来写，避免后续扩容或者迁移的时候路径乱掉。

目录创建和权限设置直接在每台机器上执行：

bash复制mkdir -p /data/mysql
chown -R mysql:mysql /data/mysql

如果在安装MySQL前没有创建mysql系统用户，可以先执行：

bash复制useradd -r -s /sbin/nologin mysql

2.3 安装 MySQL 8.0 并完成初始化

生产环境我建议从官网下载二进制tar包安装，版本尽量选择8.0.20以上（本文示例假设为8.0.x版本），因为8.0.20之前MGR有不少bug，尤其是节点加入和退出相关的逻辑，后续版本修复了很多问题。选择二进制包安装的好处是目录结构清晰，便于多实例部署和控制版本。

下载解压并做软链接，以8.0.x为例：

bash复制tar xf mysql-8.0.x-linux-glibc2.12-x86_64.tar.xz -C /usr/local/
ln -s /usr/local/mysql-8.0.x-linux-glibc2.12-x86_64 /usr/local/mysql
echo 'export PATH=/usr/local/mysql/bin:$PATH' >> /etc/profile
source /etc/profile

然后初始化数据目录。MySQL 8.0建议用--initialize-insecure方式先初始化出空密码的root账号，这样后续首次登录不用在日志里翻临时密码，方便整条流程脚本化。

bash复制mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql

启动mysqld并用socket连接：

bash复制cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld
service mysqld start
mysql -uroot -S /tmp/mysql.sock

首次登录后立即修改root密码：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY '你的强密码';

2.4 核心参数解读：MGR 配置不是随便抄就行

接下来是重头戏。MGR有一组参数必须成对出现，少一个都会导致节点无法正常加入组复制。每一台机器的my.cnf都要加上以下配置，其中server_id和loose-group_replication_local_address每台机器必须不一样，其他参数三台保持一致。

ini复制[mysqld]
server_id = 11
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = /data/mysql/binlog
binlog_format = ROW
binlog_checksum = NONE
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot = OFF
loose-group_replication_local_address = "192.168.10.11:33061"
loose-group_replication_group_seeds = "192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061"
loose-group_replication_single_primary_mode = ON
loose-group_replication_enforce_update_everywhere_checks = OFF
loose-group_replication_communication_stack = MYSQL

逐个说下关键参数为什么这么设置。

gtid_mode = ON 和 enforce_gtid_consistency = ON 是MGR的基础，没有GTID，整个组复制机制就无法工作。

binlog_format = ROW是必须的，MGR的冲突检测依赖行级别的信息。binlog_checksum = NONE也必须是NONE，如果开启checksum会导致组节点间传输的数据校验不一致。这两个参数配置错的话，后面的启动大概率会报错。

transaction_write_set_extraction = XXHASH64是为冲突检测服务的，它把行级写入指纹提取出来，用于判断不同节点是否有冲突写入。

loose-前缀的意思是这个参数可能没有被当前MySQL版本显式声明，以插件/组件形式提供，加loose-可以让mysqld在参数未知时不至于启动失败。这种写法在MGR配置里是标准做法，不用纠结。

group_replication_group_name本身要求是一个合法的UUID，可以直接用mysql的UUID()函数生成一个，也可以手动指定一个固定值。注意三台机器必须一模一样，否则无法加入同一个组。

这里要特别强调一个容易被误解的参数：group_replication_start_on_boot。生产环境我建议设为OFF，也就是不让MySQL进程启动时自动拉起MGR。原因很简单：万一某次机房断电后所有节点同时重启，如果都自动尝试启动组复制，可能会出现多个节点都尝试引导、或者节点加入顺序混乱的问题。手动控制MGR的启动顺序，在任何故障恢复场景下都能做到心里有数。

修改完my.cnf后重启mysqld，让所有参数生效：

bash复制service mysqld restart

然后在每个节点上确认参数已经正确加载：

sql复制SHOW VARIABLES LIKE 'group_replication%';

确认看到loose_group_replication_group_name、loose_group_replication_group_seeds等参数都正常显示后再继续下一步。

3. 从零搭建 MGR 单主集群：脚本级实操

3.1 节点一：创建复制账号并引导第一个组

下面开始真正的搭建流程。所有操作都建议用root账号执行，因为后面要用到SUPER权限。

第一步，在主节点（db01）上创建MGR专用的复制账号。为什么要专门建一个账号而不是用root？因为MGR节点间同步数据需要独立的复制通道，账号职责分离是生产环境的底线。同时，执行这一步前需要先关闭当前会话的binlog记录，避免账号创建语句被复制到其他还没加入组的节点上，导致后续权限混乱。

sql复制SET SQL_LOG_BIN = 0;
CREATE USER 'mgr_repl'@'%' IDENTIFIED BY '复制专用强密码';
GRANT REPLICATION SLAVE, REPLICATION CLIENT, BACKUP_ADMIN, GROUP_REPLICATION_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'mgr_repl'@'%';
GRANT SELECT ON performance_schema.* TO 'mgr_repl'@'%';
SET SQL_LOG_BIN = 1;

这里给一个实用建议：CREATE USER的密码里尽量不要包含单引号、分号这类特殊字符，否则后续在命令行脚本里容易引发转义问题。我的习惯是用大小写字母加数字的16位密码，不用符号。

第二步，配置组复制的恢复通道。MGR在节点加入时，会通过一个名为group_replication_recovery的复制通道从其他在线成员拉取缺失的数据，所以必须提前告诉它用哪个账号连接。

sql复制CHANGE MASTER TO MASTER_USER='mgr_repl', MASTER_PASSWORD='复制专用强密码' FOR CHANNEL 'group_replication_recovery';

注意，这一步不需要指定MASTER_HOST，因为MGR会从group_replication_group_seeds参数里自动发现可用的种子节点。

第三步，启动第一个组。第一个节点启动前一定要先开启bootstrap引导模式，相当于告诉组复制“我是这个组的第一个成员，我来创建这个组”。如果跳过这一步直接START GROUP_REPLICATION，节点会一直处于RECOVERING状态然后报错，因为它在组里找不到任何已有的成员。

sql复制SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

启动后立刻关闭bootstrap模式，这是为了防止以后某次误操作把这个节点再次当成新组启动，导致脑裂风险。引导完成后，用下面这条SQL确认节点状态：

sql复制SELECT * FROM performance_schema.replication_group_members\G

正常会看到一行记录，MEMBER_STATE为ONLINE，MEMBER_ROLE为PRIMARY。此时MGR的第一个节点已经就绪。

3.2 节点二和节点三：加入组的两种姿势

第二、第三节点是整个搭建过程中最容易让人心态崩溃的环节，因为报错种类多，而且不同的环境原因还不一样。

先给两条每台机器都要执行的前置语句和账号创建，和主节点一模一样的操作，确保每个节点都有独立的复制账号：

sql复制SET SQL_LOG_BIN = 0;
CREATE USER 'mgr_repl'@'%' IDENTIFIED BY '复制专用强密码';
GRANT REPLICATION SLAVE, REPLICATION CLIENT, BACKUP_ADMIN, GROUP_REPLICATION_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'mgr_repl'@'%';
GRANT SELECT ON performance_schema.* TO 'mgr_repl'@'%';
SET SQL_LOG_BIN = 1;
CHANGE MASTER TO MASTER_USER='mgr_repl', MASTER_PASSWORD='复制专用强密码' FOR CHANNEL 'group_replication_recovery';

这里说明一下为什么在从节点也要先创建复制账号。你可能会想：“主节点创建的账号不是能通过binlog复制过来吗？”其实不行——这个账号是在开启组复制前创建的，而且我们有意把SQL_LOG_BIN设为0了，它不会被复制同步。每个节点本地创建好同样的账号是官方推荐做法，防止依赖复制关系导致账号不一致。

节点二和节点三分成两种情况：

如果你是从零开始的全新空实例，数据很少，直接执行START GROUP_REPLICATION即可，它会自动通过group_replication_recovery通道从作为种子节点的db01拉取全量数据。这个方式适合测试环境或数据量在几个GB以内的场景。

如果生产库已经有大量数据，比如超过几十GB，或者binlog保留时间太短，全量追数据可能追不上，需要先用备份工具把主库的全量数据导到新节点，再启动组复制。这里不展开物理备份的细节，但思路是：用xtrabackup在db01上做一次全量备份，恢复到db02，恢复后确保db02的mysqld能正常启动，并且GTID集合与主库一致。然后再执行START GROUP_REPLICATION，它只需要补上备份之后的增量事务。

在db02上直接启动：

sql复制START GROUP_REPLICATION;
SELECT * FROM performance_schema.replication_group_members\G

如果看到db02状态是ONLINE，角色是SECONDARY，说明加入成功。db03按同样方式操作。

三节点全部变成ONLINE后，在任意一个节点查看组状态：

sql复制SELECT MEMBER_ID, MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;

正常输出是三行，一个是PRIMARY，两个是SECONDARY，状态都是ONLINE。

3.3 MGR 生产参数调优：默认值不够用

MGR能跑起来不等于适合生产，有几个参数在真正上线前建议根据业务情况调整。

group_replication_member_expel_timeout参数默认是0，含义是一个节点被判定为可疑后立即开始驱逐计时，如果网络抖动超过几秒，节点可能被组内其他成员踢出。生产环境网络设备升级、交换机割接时常有秒级闪断，我建议设置为5到10，给网络抖动留一点缓冲时间，避免MGR因为一次短暂抖动就踢掉一个健康节点。

这个参数是online可以动态调整的，在组内执行：

sql复制SET GLOBAL group_replication_member_expel_timeout = 5;

group_replication_flow_control_mode默认是QUOTA，表示开启流控。流控机制会限制写入速度，避免备节点apply跟不上主节点，导致组内成员积压太多。测试压测时经常遇到写入吞吐达不到预期，把流控关掉：

sql复制SET GLOBAL group_replication_flow_control_mode = 'DISABLED';

生产环境最好不要长期关闭流控，除非你对主备节点的硬件性能差异非常有信心。我见过因关闭流控导致备节点长时间积压，最终被网络断连踢出组的案例。建议保留默认值或做大压测时临时关闭。

super_read_only参数在MGR从节点上默认就是ON，这是对的，不要动它。单主模式下从库本就不可写，所有写操作必须走PRIMARY节点。

4. KeepAlived 的正确玩法：不是帮 MySQL 抢 IP，而是替业务找主库

4.1 为什么不能只看“进程存活”来判断是否接管VIP

这是全篇最核心的一个认知。很多网上教程里的KeepAlived配置简单粗暴：检测mysqld进程是否存在，进程活着就认为节点健康，VIP就归它。这套逻辑在主从复制架构下勉强能工作，因为主库一般在固定节点；但在MGR环境下，主库是会漂移的。

假设db01是当前PRIMARY，db02和db03是SECONDARY。如果db01的业务压力过大导致MGR把它驱逐出组，但mysqld进程本身还活着，KeepAlived的进程检测会认为“数据库是好的”，VIP继续留在db01上。但实际上db01已经不是PRIMARY，MGR已经在db02上选出了新主，业务对VIP的写请求全部失败。这是我在实际项目中遇到的最常见的MGR切换事故，没有之一。

正确思路是：KeepAlived的健康检测不是检查“MySQL进程活着没有”，而是检查“本机是否仍然是MGR的PRIMARY节点”。是，就持有VIP；不是，立刻让出VIP。

4.2 KeepAlived 安装和基于单播的配置

安装KeepAlived非常简单，多数Linux发行版都有现成软件包：

bash复制yum install -y keepalived

也可以用源码编译安装，但对于绝大多数场景，系统自带的版本够用了。我这里给出的是2.x版本的配置语法。

在继续之前，要先说一个重要问题——VRRP报文默认走组播。生产环境很多交换机会禁用组播，而且云环境支持组播的也极少。如果KeepAlived的VRRP通告发不出去，两台机器会互相认为对方宕机，然后各绑各的VIP，网络直接冲突。

解决方案是使用单播模式，在配置里显式声明对端IP。这样可以绕过组播限制，同时在安全上也更可控。

以下是一份三节点完整配置文件示例，每台机器有少量差异，我逐项说明。

ini复制global_defs {
    router_id LVS_MYSQL_01
    vrrp_skip_check_adv_addr
    vrrp_strict
}

vrrp_script chk_mysql {
    script "/etc/keepalived/check_mysql_mgr.sh"
    interval 2
    fall 2
    rise 2
    timeout 2
}

vrrp_instance VI_MYSQL {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }

    unicast_src_ip 192.168.10.11
    unicast_peer {
        192.168.10.12
        192.168.10.13
    }

    virtual_ipaddress {
        192.168.10.100/24 dev eth0 label eth0:vip
    }

    track_script {
        chk_mysql
    }

    notify_master "/etc/keepalived/notify_master.sh"
    notify_backup "/etc/keepalived/notify_backup.sh"
    notify_fault "/etc/keepalived/notify_fault.sh"
}

第二台机器改动三点：router_id改成LVS_MYSQL_02，unicast_src_ip改成自己IP，unicast_peer列表里写另外两台；priority改成90。第三台同样操作，priority改成80。

请读者注意：这里的priority不同，并不是用来决定谁是“数据库主库”的，而是给KeepAlived在极端情况下“谁先抢占VIP”提供一个基准排序。真正控制VIP归属的是check_mysql_mgr.sh脚本返回状态。所有节点state都设为BACKUP，而不是MASTER，这样能避免原本MASTER节点恢复后跟当前实际承载VIP的节点发生不必要抢占。

4.3 核心脚本：三行SQL判断本机该不该持有VIP

配置文件的灵魂是chk_mysql_script，脚本的返回值直接决定KeepAlived的健康状态。脚本逻辑其实不复杂，查询performance_schema里的replication_group_members表，找到MEMBER_UUID等于本机server_uuid且MEMBER_STATE为ONLINE的记录，看它的MEMBER_ROLE是不是PRIMARY。

我把脚本写成了比较完整的版本：

bash复制#!/bin/bash
MYSQL_USER="root"
MYSQL_PASS="你的root密码"
MYSQL_SOCK="/tmp/mysql.sock"

mysql -u${MYSQL_USER} -p${MYSQL_PASS} -S ${MYSQL_SOCK} -e "SELECT 1 FROM performance_schema.replication_group_members WHERE MEMBER_UUID = @@server_uuid AND MEMBER_STATE = 'ONLINE' AND MEMBER_ROLE = 'PRIMARY';" >/dev/null 2>&1
exit $?

解释一下脚本思路：如果本机是PRIMARY，这条SQL能查出一行结果，mysql命令返回0，KeepAlived认为健康；如果不是PRIMARY或者状态不是ONLINE，SQL返回空，mysql命令的退出码非0，KeepAlived认为不健康。

注意脚本里的权限问题。root账号直接写在脚本里虽然省事，但安全性欠佳。如果没有给脚本单独授权账号，可以用具有performance_schema只读权限的监控账号：

sql复制CREATE USER 'mgr_monitor'@'localhost' IDENTIFIED BY '监控密码';
GRANT SELECT ON performance_schema.* TO 'mgr_monitor'@'localhost';

然后把脚本里连接信息改成这个账号。这只是最小权限方案，如果后续要加更多监控维度，再按需扩大权限。

脚本创建后，必须赋予可执行权限，并用root手动执行一次验证返回码：

bash复制chmod +x /etc/keepalived/check_mysql_mgr.sh
/etc/keepalived/check_mysql_mgr.sh
echo $?

在PRIMARY节点上执行，期望输出0；在SECONDARY节点上执行，期望输出1。如果返回结果不对，先排查账号权限、socket路径、SQL本身。

4.4 KeepAlived 状态切换通知脚本

notify脚本的作用是在节点状态变化时执行一些额外动作。通常我建议在notify_master里做两件事：把本机状态写入日志文件，以及把当前角色记录到一个文本文件供监控读取。

以notify_master.sh为例：

bash复制#!/bin/bash
LOGFILE="/var/log/mysql_mgr.log"
echo "$(date '+%F %T') [MASTER] $HOSTNAME becomes MGR PRIMARY, ready to hold VIP" >> ${LOGFILE}

notify_backup和notify_fault类似，记录成为备库或进入故障状态的时间点。不用写太复杂，真正的高可用逻辑在脚本返回码里已经完成了，notify脚本只是让后续审计和故障复盘时有迹可循。

这些脚本同样要chmod +x。不要忽略这一步，否则KeepAlived启动时会报没有执行权限的错误，导致脚本永远不生效。

配置完成后，在三个节点依次启动KeepAlived服务：

bash复制systemctl start keepalived
systemctl enable keepalived

在PRIMARY节点上检查VIP是否正常绑定：

bash复制ip addr show eth0

正常情况下，能看到192.168.10.100已经绑定在eth0上。此时用MySQL客户端通过VIP连接测试：

bash复制mysql -h192.168.10.100 -uroot -p

能正常登录说明整套链路已经打通。

5. 高可用验证：敢做才叫生产级

5.1 故障注入前的基线检查和确认

很多团队搭完MGR和KeepAlived，看一眼节点状态都正常，就敢上生产了。结果第一次故障演练，直接发现VIP在几台机器之间“鬼打墙”一样飘忽不定。所以在做任何故障测试前，先确认基线状态。

用MySQL客户端连上VIP，执行下面的查询：

sql复制SELECT @@server_uuid;

然后到performance_schema表里对比：

sql复制SELECT MEMBER_UUID, MEMBER_HOST, MEMBER_ROLE, MEMBER_STATE FROM performance_schema.replication_group_members;

VIP所在的机器，它的server_uuid必须等于表里MEMBER_ROLE为PRIMARY那行的MEMBER_UUID。如果VIP停在一台SECONDARY上，说明脚本或配置有问题，先别继续往下测。

5.2 主库进程宕机演练：观察切换时间与业务中断窗口

在PRIMARY节点db01上执行：

bash复制kill -9 $(pidof mysqld)

这是最粗暴的故障模拟，把MySQL进程直接杀掉，相当于是断电级别的故障。执行后立刻在db01上观察KeepAlived状态，在db02上观察MGR状态。

正常情况下，动作会根据时序分两步发生：

MGR组内其他节点会在几秒内检测到db01失联，然后多数派节点会重新选举PRIMARY。由于我们在配置中设置了group_replication_member_expel_timeout = 5，这个检测窗口会在5秒后完成。db02被选为新PRIMARY。

db02和db03上的check_mysql_mgr.sh脚本在下一个检查周期（2秒）内会发现自己是PRIMARY，返回0，于是db02的KeepAlived开始接管VIP。

整个切换时间大约在5到10秒之间。这个时间窗口就是业务真实感受到的不可用时间。如果想缩短，可以把expel_timeout调低到0并加快检查频率，但生产环境我不建议太激进，因为网络抖动的误踢成本往往比几秒的业务中断要高。

验证新主库和VIP关系时，执行：

bash复制ip addr show eth0

db02上如果能看到VIP，说明KeepAlived已经正确地把VIP漂移到了新主库。再通过VIP连接MySQL，插入一条测试数据，能成功说明切换完整生效。

5.3 原主库节点重新恢复：踩过的坑一次说清

故障排除后把db01重新开机，mysqld启动。但注意，mysqld起来不等于MGR自动恢复。因为我们在配置里设置了group_replication_start_on_boot = OFF，所以db01启动后需要手动执行：

sql复制START GROUP_REPLICATION;

如果一切正常，db01会重新加入原组，自动通过复制通道补上宕机期间的数据，状态从RECOVERING变成ONLINE，角色是SECONDARY。这次切换过程中，db01不需要重新引导组，因为组还存在，db02已经是PRIMARY。

这里有个非常常见的场景需要单独说明：如果整个集群所有节点都断电了，比如机房整体故障停电，恢复时应该怎么操作？

正确做法是，选一台你确定拥有最新数据的节点（通常是之前记录中最后成为PRIMARY的那台），先在它的配置里临时打开bootstrap设置，然后启动组复制：

sql复制SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

再启动其他节点的组复制，让它们自动加入组。千万注意：如果选错了节点，或者同时让两台机器开启了bootstrap，就可能出现两个独立的“组”，数据从此分叉。恢复操作前一定要人工确认哪台机器拥有最新事务，而不是盲目选第一台能启动的机器。

5.4 脑裂为什么没有发生：说明一个让人容易误解的点

有朋友会问：三节点MGR故障后，如何保证不会一个分区认为自己有主库，另一个分区也认为自己有主库？要理解这一点，关键在组复制的验证机制。一个SECONDARY节点想把自己提升为PRIMARY，不靠KeepAlived决定，而是靠它能在组内获得多数派节点的确认。当db01被kill后，db02和db03之间依然可以通信，它们构成多数派，因此能合法选出新PRIMARY。而db01即使重启后想重新加入组，也必须与组内现有成员同步数据，而不是自己拉一批老数据自立为王。

KeepAlived在这个机制中只是“依附”在MGR的结论上。它本身没有判断数据一致性的能力，但它通过脚本检测了MGR的MEMBER_ROLE，等于把数据库层选主的结果忠实地反映到了VIP漂移上。理解了这层逻辑，就不会担心脚本误判导致脑裂了。

如果还想更保险，可以在check脚本里增加一条验证：只有当本机是PRIMARY且组内成员数量大于等于2时才返回0。不过在实际环境中，单主模式+多数派机制已经能拦住绝大多数场景，加这条主要是防止某些极端情况下PRIMARY短暂孤立时VIP被错误拉起。

6. 常见问题与排错速查：部署现场的救火手册

6.1 MGR部分最容易出现的五个问题

把我在生产现场和社区答疑中反复遇到的MGR问题整理成了表格，按出现频率排序。

排查RECOVERING问题是MGR运维的基本功，一条SQL定位问题方向：

sql复制SELECT * FROM performance_schema.replication_connection_status\G

重点看LAST_ERROR_MESSAGE字段，这里会直接告诉你恢复失败的真实原因。如果错误信息指向复制连接失败，再确认账号；如果指向已经在接收数据但一直没完成，则检查数据追赶进度。

6.2 KeepAlived部分最常见的三个问题

KeepAlived配置本身不复杂，但出了问题很难察觉，因为它在不出事时看起来一切正常。

VIP启动后一直不出现，大概率是vrrp_strict对防火墙规则限制太严格。vrrp_strict模式下需要显式放行VRRP协议。我的建议是如果不用特别严格的安全策略，可以注释掉vrrp_strict，只保留router_id、interface这些基础参数。

反过来，VIP出现后又反复跳变，两台机器抢IP，往往是检测脚本返回码不稳定导致的。