光慢光慢1. 先想清楚：MGR 和 KeepAlived 在这套方案里到底各自扮演什么角色
1.1 MySQL 8.0 MGR 单主模式解决了什么问题
MySQL 8.0 的 Group Replication，简称 MGR，本质上是一套基于组通信协议的高可用复制方案。它和传统异步主从复制最大的区别在于：成员之间通过 Paxos 类共识协议交换消息，组内所有节点对“谁还能写入”“谁已经故障”能达成一致，而不是靠半同步、MHA 这类外部脚本去猜。
生产上用 MGR 通常都是用单主模式。在这个模式下，同一时间只有一个节点是 PRIMARY，可以接收写事务，其他节点都是 SECONDARY，只同步和提供只读能力。PRIMARY 节点发生故障时，剩余成员会协商出一个新 PRIMARY，不需要人工介入。
MGR 对“丢数据”这件事的控制比传统异步复制严密得多。传统主从里，主库 binlog 刷盘了，从库可能还没拿到，一旦主库断电，切到从库就会丢这一段；MGR 则会要求事务在组内多数成员上确认后才提交，多数派活着数据就在。用一句大白话说，主从复制像是把账本交给徒弟抄写，徒弟抄到哪页算哪页；MGR 更像几个记账员同时对账，至少一半以上的人确认这笔账没问题，才正式落账。
这套方案适合对数据一致性要求较高、又不希望引入太重的外部协调组件的场景。很多公司数据库规模并不大，三台物理机或虚拟机就能组成一套高可用集群，应用连接一个虚拟 IP，剩下的故障切换逻辑交给集群和 VIP 脚本处理。
1.2 为什么还要在 MGR 上面加 KeepAlived
MGR 解决了数据库内部的主节点选举和数据一致问题，但它不给客户端提供“入口漂移”能力。应用层不可能每次写 SQL 前先查一下当前哪个节点是 PRIMARY，总要有一个固定的访问地址。这个地址就是 VIP，虚拟 IP。
KeepAlived 在这套方案里承担的就是 VIP 漂移工作。它用 VRRP 协议在多个节点之间维持一个虚拟 IP，正常情况下 VIP 落在 PRIMARY 节点上，节点故障或角色变化后，VIP 自动挪到新的 PRIMARY 节点。应用层看到的是同一个 IP，不需要改连接串，数据库内部的主从切换对业务透明。
很多人会问，既然 MySQL 官方有 InnoDB Cluster + MySQL Router，为什么还要自己拼 MGR + KeepAlived？我的看法是，InnoDB Cluster 适合愿意接受全套官方生态、统一管理工具链的环境；但不少线上环境已经有自己的监控、备份、发布体系，只想把数据库复制层和高可用入口层拆开管理。KeepAlived 轻量、配置直接、故障点少，和 MGR 组合起来足够应付大部分单主读写场景。
另外一个常见困惑是“Haproxy 和 KeepAlived 到底用哪个”。KeepAlived 主要管 VIP 漂移，本身不处理七层转发；Haproxy 主要做 TCP/HTTP 负载均衡。如果你的业务需要多个只读节点分担读流量、需要按端口转发，可以在 MGR 前面放 Haproxy，再用 KeepAlived 给 Haproxy 机器做高可用。但如果你只需要一个写入口加几个只读备份节点，直接把 VIP 绑在 MGR PRIMARY 节点上更简单，少一层代理就少一层故障面。
1.3 方案边界和使用前提
MGR 并不是万能的。它对网络质量要求比较高，节点之间一般建议同机房或低延迟专线，跨城域网的组复制会频繁出现延迟和成员踢出问题。同时，单主模式只适合写多读少的业务，如果读压力很大，要么扩展 MGR 成员数量，要么在 MGR 上层再做读写分离。
还有一个常见误区是把 MGR 当成“自动故障转移全家桶”。MGR 只保证数据库组件内达成共识，对外暴露持续可用的连接入口是 KeepAlived 要做的事；监控告警、应用重试、数据备份这些还得自己搭。本文后面的配置也全部围绕“生产可用”这四个字展开，不是只搭个实验环境跑通就结束。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的节点规划与 MySQL 8.0 安装
2.1 主机规划、端口规划与版本选择
一套三节点 MGR 集群至少需要三台主机，原因是组复制要避免“双脑”，多数派协议决定了集群必须能容忍一台机器宕机，至少三台才能形成多数派。两台节点的 MGR 没有意义，一台挂掉就达不到多数派，整个组会阻塞或解体。
下面是我常用的规划方式。假设三台机器 IP 分别为 192.168.56.101、192.168.56.102、192.168.56.103，MySQL 实例端口统一用 3306，组复制内部通信端口用 33061。注意 33061 这个端口很多第一次搭 MGR 的人会忘记放防火墙，后面节点加入时永远卡在 RECOVERING，问题排查非常痛苦。
| 节点 | IP | 操作系统 | MySQL 版本 | 组复制本地通信端口 |
|---|---|---|---|---|
| mgr-node1 | 192.168.56.101 | CentOS 7.9 / 8.x | 8.0.32 | 33061 |
| mgr-node2 | 192.168.56.102 | CentOS 7.9 / 8.x | 8.0.32 | 33061 |
| mgr-node3 | 192.168.56.103 | CentOS 7.9 / 8.x | 8.0.32 | 33061 |
MySQL 版本建议选 8.0.27 以上的稳定版。8.0.27 之后 Group Replication 的很多消息通信机制有优化，8.0.18 之前的老版本对 IPv6、部分系统配置兼容性差。这里用 8.0.32 举例，生产上选你验证过的同一个大版本即可，三台节点小版本尽量保持一致，避免出现协议兼容问题。
2.2 MySQL 8.0 二进制安装与基础初始化
生产环境我个人更推荐用官方 tar 包或 RPM 安装，尽量不用 Docker 跑数据库。Docker 本身不是不能用，但 MGR 对网络和端口非常敏感，容器网络的 NAT 会把 report_host、group_replication_local_address 这些地址搞得很复杂，排查成本远