MySQL 8.4 MGR组复制三节点单主高可用搭建实战与排错

如果你和我一样手上的 MySQL 刚好是 8.4.7又被要求尽快把主从高可用搭起来那组复制MySQL Group Replication简称 MGR基本是绕不开的选项。这篇文章是我从零开始搭三节点单主 MGR 的完整记录包含 8.4 版本里和旧版本差异很大的初始化、SSL、插件加载细节也把搭建时会遇到的典型报错和修复方法整理了最后补充了 Docker、Kubernetes 环境下的落地要点。适合刚接手 MySQL 8.x 的 DBA、准备做高可用改造的架构师以及那些看到一堆 group_replication_* 参数就头疼的同学。1. 为什么这次我选了组复制而不是传统主从1.1 传统主从复制哪里不够用MySQL 的传统主从复制本质是异步复制主库把 binlog 推给从库从库回放主库并不确认从库是否真正拿到日志。正常场景下延迟可能只有几十毫秒可一旦主库宕机还没推出去的 binlog 就丢了。很多人为了缩小这个窗口上了半同步复制但半同步在网络抖动时很容易退化成异步而且主从切换还是要依赖 MHA、Orchestrator 这类第三方工具脚本写得再小心总有些边界情况处理不干净。MGR 解决的就是这两件事一是用共识协议保证日志顺序和成员状态统一二是把“谁当主库”的决策从外部脚本搬到了数据库内部。它不是异步复制也不是简单的半同步而是组内每个节点都维护自己的 binlog同时通过组通信层确认事务提交顺序再执行冲突检测。只要多数派节点活着整个组就能继续工作主节点挂了会自动选出新主数据不会因为“日志还没传过去”就直接丢。我用 8.4.7 搭建前查过版本情况MySQL 8.4 已经是 LTS 版本组复制插件从 8.0 开始不断演进到 8.4 这一代稳定性和性能都算成熟。三节点单主模式既能做到故障自动切换又不需要引入额外协调组件比我自己二开一套高可用脚本要可靠得多。1.2 MGR 单主和多主怎么选MGR 有两种模式单主single-primary和多主multi-primary。单主模式里同一时刻只有一个节点接受读写其余节点是只读备库多主模式允许所有节点写入。标题虽然叫“主从搭建”但从生产稳定性出发我强烈建议你第一套先做单主。多主模式最大的坑是冲突检测两个节点同时改同一行哪怕最终能成功一个业务侧也可能报主键冲突或更新丢失。真要上多主业务必须把写入按维度拆分到不同节点比如按用户 ID 分片、按区域分片让同一条数据尽量只在同一个节点上写。这个改造量远超多数业务愿意付出的成本。所以本文的配置都按单主模式来相关参数是这两组group_replication_single_primary_modeON group_replication_enforce_update_everywhere_checksOFF这两行是配套的。如果开了 enforce_update_everywhere_checks单主模式会被强制改成多主。第一次配 MGR 的人最容易栽在这里。2. 8.4.7 环境准备安装初始化容易翻车的地方2.1 安装包选择与依赖我先说结论能用官方二进制包就别用系统自带的发行版包能在线装就选官方 Yum 仓库离线环境用 RPM 包配合本地目录。我这次三台机器都是 Rocky Linux 9生产环境不允许直接连外网所以走的离线 RPM 路线。需要准备这几类文件mysql-community-server-8.4.7-1.el9.x86_64.rpm mysql-community-client-8.4.7-1.el9.x86_64.rpm mysql-community-common-8.4.7-1.el9.x86_64.rpm mysql-community-libs-8.4.7-1.el9.x86_64.rpm mysql-community-client-plugins-8.4.7-1.el9.x86_64.rpm mysql-community-icu-data-files-8.4.7-1.el9.x86_64.rpm安装前检查系统依赖特别是 libaio。RPM 安装时缺依赖最常见的报错就是它yum install -y libaio ncurses-compat-libs perl rpm -ivh mysql-community-*.rpm装完之后最好再确认一次版本防止某台机器装歪了变成 8.0mysqld --version如果是用官方 Yum 仓库在线安装先确认仓库里默认的版本号是 8.4 而不是 8.0。这一步看起来不起眼实际踩过的人不少配了半天 MGR 参数最后发现三个节点版本不一致光排查就浪费半天。2.2 初始化实例和 8.4 默认行为变化RPM 安装完会自动创建 mysql 用户和 /var/lib/mysql 目录但不代表实例已经初始化。8.4 版本的初始化命令和 8.0 基本一致mysqld --initialize --usermysql执行完后去 error log 里翻临时密码grep temporary password /var/log/mysqld.log然后启动服务systemctl start mysqld systemctl enable mysqld mysql -uroot -p登录后第一步强制改密码ALTER USER rootlocalhost IDENTIFIED BY Your_Strong_Pass_2024;这里要特别提醒 8.4 的几个默认行为变化默认认证插件已经是 caching_sha2_password不再是 mysql_native_password。8.4 里 mysql_native_password 插件默认不再加载所以不要再用“IDENTIFIED WITH mysql_native_password BY” 这种写法去建复制账号否则直接报错。SSL 默认是开启的实例会自动生成自签名证书。这个和旧版本差异很大旧脚本里如果写了“关闭 SSL 以提升性能”之类的操作在 8.4 上会遇到组复制 recovery 通道连不上。某些默认值也被调整过比如 secure_file_priv 默认是 NULL意味着 LOAD DATA INFILE 之类操作默认被限制。组复制不直接依赖它但如果后续要从文件初始化数据需要提前调好。节点初始化完成后建议先单独确认本机 root 能正常登录、socket 路径是什么再往下走。否则后面一遇到 ERROR 2002你会分不清是初始化失败还是配置写错。2.3 三节点基础配置模板我用的三台机器地址是 172.16.20.21、172.16.20.22、172.16.20.23每台机器上 MySQL 版本统一是 8.4.7。MGR 三个节点至少要保证这些参数一致[mysqld] server_id1 gtid_modeON enforce_gtid_consistencyON binlog_formatROW binlog_checksumNONE log_slave_updatesON relay_log_recoveryON master_info_repositoryTABLE relay_log_info_repositoryTABLE transaction_write_set_extractionXXHASH64 binlog_row_imageFULL plugin_load_addgroup_replication.so group_replication_group_name6b8f499a-9f34-11ee-9b9e-005056a2b8df group_replication_start_on_bootOFF group_replication_bootstrap_groupOFF group_replication_single_primary_modeON group_replication_enforce_update_everywhere_checksOFF group_replication_local_address172.16.20.21:33061 group_replication_group_seeds172.16.20.21:33061,172.16.20.22:33061,172.16.20.23:33061 group_replication_ip_allowlist172.16.20.0/24 group_replication_exit_state_actionREAD_ONLY loose-group_replication_recovery_use_sslON loose-group_replication_recovery_ssl_verify_server_certOFF不同节点只需要改四处节点server_idreport_hostgroup_replication_local_addressmysql-11172.16.20.21172.16.20.21:33061mysql-22172.16.20.22172.16.20.22:33061mysql-33172.16.20.23172.16.20.23:33061group_replication_group_name 是组名官方要求必须是合法 UUID我习惯用SELECT UUID()生成一个而不是手写。group_replication_start_on_boot 在生产上我故意设为 OFF别小看这个默认值如果设为 ON节点重启后会自动尝试加入组一旦组还没 bootstrap 或者网络抖动会出现各种奇怪的日志。我宁可在服务启动后手动 START GROUP_REPLICATION也不要让节点“自动归队”。3. 单主组复制搭建全流程三节点实战3.1 第一个节点初始化组三台机器把 my.cnf 改好并重启 mysqld 后先用 root 登录第一台节点确认插件已经加载SHOW PLUGINS;看到 group_replication 状态为 ACTIVE 就说明 plugin_load_add 生效了。如果没看到手动执行INSTALL PLUGIN group_replication SONAME group_replication.so;接着创建组复制专用账号。这个账号至少需要 REPLICATION SLAVE、REPLICATION CLIENT、BACKUP_ADMIN、CLONE_ADMIN8.4 里还要单独给 GROUP_REPLICATION_STREAM否则后面恢复通道会报权限不足CREATE USER mgr_repl% IDENTIFIED BY Mgr_Repl_Pass_2024; GRANT REPLICATION SLAVE, REPLICATION CLIENT, BACKUP_ADMIN, CLONE_ADMIN, GROUP_REPLICATION_STREAM ON *.* TO mgr_repl%; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE ON *.* TO mgr_repl%;然后在每个节点上把复制通道指向这个账号。8.4 里旧命令 CHANGE MASTER TO 还保留但会打 deprecated 告警直接用新写法CHANGE REPLICATION SOURCE TO SOURCE_USERmgr_repl, SOURCE_PASSWORDMgr_Repl_Pass_2024 FOR CHANNEL group_replication_recovery;最后回到第一台节点先把 bootstrap 开关打开再启动组SET GLOBAL group_replication_bootstrap_groupON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_groupOFF;必须注意bootstrap_group 只应该在第一台节点第一次启动组时打开其他节点永远不要开。这个开关说白了就是告诉其他成员“我是源头”一旦多开就会出现多个“源头”轻则组分裂重则数据错乱。启动后立即查成员状态SELECT member_id, member_host, member_port, member_state, member_role FROM performance_schema.replication_group_members;正常情况下第一台节点应该显示 ONLINE、PRIMARY。3.2 第二、第三个节点加入第二、第三台节点需要完全相同的前置步骤改好 my.cnf、建复制账号、配置 group_replication_recovery 通道。然后什么都不用 bootstrap直接执行START GROUP_REPLICATION;如果一切顺利一两秒后就能看到三台节点全部 ONLINE。需要注意的是第二、第三台节点第一次加入时会从现有 PRIMARY 节点拉取数据回放这个过程叫分布式恢复。只要 PRIMARY 上 binlog 还没有被清理新节点就能自动补全数据。如果第二、第三节点曾经是独立实例自己产生过 GTID 事务加入时会报“GTID 不一致”的错误。这时候不要硬加最省事的办法是把该节点数据目录清掉重新初始化让它以一个“空白实例”身份加入也可以使用 Clone 插件从 PRIMARY 打底SET GLOBAL clone_valid_donor_list 172.16.20.21:3306; CLONE INSTANCE FROM mgr_repl172.16.20.21 IDENTIFIED BY Mgr_Repl_Pass_2024;Clone 完成后实例会自动重启重启后再配置 recovery 通道然后 START GROUP_REPLICATION。这套流程对数据量大的节点非常友好不用手动导出一晚上才同步完。3.3 功能验证与日常维护三节点全部 ONLINE 后我在 PRIMARY 上建了一个测试库和一张带主键的表插入几条数据CREATE DATABASE app_test; USE app_test; CREATE TABLE t_user ( id INT PRIMARY KEY, name VARCHAR(64) ); INSERT INTO t_user VALUES (1, zhangsan), (2, lisi);然后分别在两个备库上查询能看到同样的数据说明异步恢复通道和 applier 都正常。注意 MGR 强制要求业务表必须有主键原因也很好理解组复制要判断事务是否冲突需要记录行级别写集并做冲突校验没有主键就没法精确标识行。接着模拟一次主库故障。我直接在主库上执行 STOP GROUP_REPLICATION模拟异常退出STOP GROUP_REPLICATION;等待几秒再看成员状态会看到剩余两台节点自动选出了新的 PRIMARY。整个过程不需要任何手工切换脚本业务连接如果走了 VIP 或负载均衡只需要把读写入口重新指向新主即可。日常维护时最常用的两个查询-- 查看组成员健康度 SELECT * FROM performance_schema.replication_group_members; -- 查看每个成员的事务统计与流量控制 SELECT * FROM performance_schema.replication_group_member_stats\G4. 排错实录搭建和压测中踩过的坑4.1 ERROR 2002socket 连不上搭建过程中最容易遇到的问题不是组复制本身而是客户端连不上本地 MySQL报错长这样ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock这种报错八成是 socket 路径不一致。MySQL 客户端默认去 /tmp/mysql.sock 找 socket但 8.4 的服务端 socket 位置通常配置成了 /var/run/mysqld/mysqld.sock。解决办法有两个方向先检测 socket 实际位置mysqladmin --socket/var/run/mysqld/mysqld.sock ping能通就直接连mysql -uroot -p -S /var/run/mysqld/mysqld.sock长期方案是在 my.cnf 的 [client] 区段显式指定 socket 路径避免不同客户端工具读取到不同配置。这不是 MGR 特有的问题但组复制搭建要反复登录、反复查状态socket 对不上会浪费很多不必要的时间。4.2 recovery 阶段的 SSL 报错第二台节点执行 START GROUP_REPLICATION 后成员状态一直停留在 RECOVERING查看恢复通道错误SELECT CHANNEL_NAME, SERVICE_STATE, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME group_replication_recovery\G我遇到的报错是ERROR 2026 (HY000): SSL connection error: error during SSL handshake原因在于 8.4 默认开启 SSL复制恢复通道默认也要求走 SSL但节点之间可能因为证书、TLS 版本不一致导致握手失败。我的处理方式是在三个节点的 my.cnf 里都显式加上这两行loose-group_replication_recovery_use_sslON loose-group_replication_recovery_ssl_verify_server_certOFF注意不要漏掉前面的 loose- 前缀。loose-这个前缀的作用是如果当前实例还没加载 group_replication 插件mysqld 启动时不会因为识别不了这个变量而报错而是把它当作未知参数忽略掉。另外如果复制账号是 caching_sha2_password 认证并且恢复通道没有走 SSL还会出现“公钥检索失败”之类的报错。8.4 下要么保证 SSL 开启要么临时打开SET GLOBAL group_replication_recovery_get_public_keyON;实测下来还是走 SSL 最干净不用去纠结公钥交换的问题。4.3 成员一直 RECOVERING卡住不动节点状态持续显示 RECOVERING但 gr_member_state 一直不到 ONLINE除了 SSL 外最常见原因有三个第一个是 donor 节点 binlog 已经清理过新节点追不到完整事务。比如数据量大的实例、binlog 保留时间很短新节点加入时拉取不到起点。解决思路是尽量用 Clone 插件打底或者临时调大 binlog 保留时间binlog_expire_logs_seconds86400需要提前确认足够的数据保留窗口再把新节点加入。第二个是新节点无法连接 donor 的 MGR 通信端口 33061。组复制节点间的通信除了默认的 3306还依赖 group_replication_local_address 指定的端口防火墙或安全组经常只放行 3306 而忘了 33061。检查方法是在备节点上直接telnet 172.16.20.21 33061第三个是复制账号权限不足。如果 group_replication_recovery 通道使用的账号缺少 BACKUP_ADMIN 或 CLONE_ADMIN加入时会报类似“ERROR 3092”的信息。我把必要的权限列一遍直接照着授权即可GRANT BACKUP_ADMIN, CLONE_ADMIN, GROUP_REPLICATION_STREAM, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO mgr_repl%;4.4 丢节点、脑裂和强制恢复组复制里最忌讳的就是“随便找一台机器 STOP GROUP_REPLICATION 再 START”。如果同一时刻有多个节点退出剩下来的节点不足以形成多数派组会进入只读状态保住数据一致性是第一优先级。如果组内剩下两个节点通常还能维持因为三节点组的多数派是 2。如果只剩一个节点或者因为网络分区两边都以为自己是“少数派”就必须用强制重配置恢复。操作方式如下在仍然存活且数据最完整的节点上SET GLOBAL group_replication_force_members172.16.20.21:33061,172.16.20.22:33061;这个命令会把组强制收缩到指定的两个节点。使用前一定要确认没有被强制切除的其他节点否则等它们恢复后再连进来可能出现脑裂和重复主节点。我自己的规矩是强制恢复这条命令必须在业务停写、并且和团队确认过数据完整性后才能执行。另外我在配置里把 group_replication_exit_state_action 设置成了 READ_ONLY而不是默认的 ABORT_SERVER。这个参数的含义是当节点因为意外原因退出组时实例是变成只读还是直接 shutdown。生产环境我建议用 READ_ONLY这样人还在MySQL 进程还在问题诊断和排查要容易得多。如果设成 ABORT_SERVER节点一退出组就直接把数据库进程关掉反而会让业务慌。5. 问题排查速查表为了方便翻阅我把搭建过程里最容易出现的问题整理成了表格按现象、原因、处理方式三列排好现象可能原因处理办法客户端报 ERROR 2002 socket 连不上socket 路径不一致用 -S 指定实际 socket或统一 [client] 配置INSTALL PLUGIN 找不到 group_replication.so安装包不完整/版本过旧确认使用官方 8.4.7 RPM 或二进制包START GROUP_REPLICATION 一直在 RECOVERINGrecovery 通道 SSL/权限/binlog 不满足检查 SSL 参数、账号权限、binlog 保留时间START GROUP_REPLICATION 报 ERROR 3096第一节点没开 bootstrap首个节点 SET GLOBAL group_replication_bootstrap_groupON 后再启动成员退出后整个组只读节点数不足多数派保持三节点或恢复节点必要时 force_members多主模式数据冲突单双主配置不一致检查 single_primary_mode 和 enforce_update_everywhere_checks节点自动重启后状态异常start_on_boot 行为影响生产环境建议保留 OFF手动控制加入时机复制用户连接时公钥检索失败caching_sha2_password 未走 SSL开启 recovery_use_ssl或临时开 get_public_key备库查询不到最新数据应用没走主节点单主模式下备库是只读读写入口必须指向 PRIMARY6. 容器和 Kubernetes 环境中落地组复制的注意点6.1 Docker 里跑 MGR 的坑有人会在 Docker 里部署 MySQL 8.4.7 来快速验证组复制。思路没问题但有几个坑建议提前避开。第一容器的 IP 不能随便漂移。MGR 的 group_replication_local_address 和 group_seeds 都依赖具体 IP容器一旦重建IP 变了节点就找不回来了。我用的办法是建一个固定的 docker 网络给每个容器指定固定 IP并把数据目录挂到宿主机docker network create --subnet172.18.0.0/24 mgr-net docker run -d \ --name mysql-mgr-1 \ --network mgr-net \ --ip 172.18.0.21 \ -e MYSQL_ROOT_PASSWORDRoot_Pass_2024 \ -v /data/mysql1:/var/lib/mysql \ mysql:8.4.7 \ --server-id1 \ --gtid-modeON \ ...容器内部的 local_address 必须写成容器自己的固定 IP不要写 localhost 或容器名。因为组内节点之间要通过这个地址互相通信写成 localhost 就只有容器内部能连。第二容器重启后 mysqld 是否自动启动组复制取决于 start_on_boot 参数。容器环境下创建新容器后配置会被重新读取我强烈建议在容器启动完成后手工执行 START GROUP_REPLICATION用健康检查脚本辅助判断而不是依赖自动归位。6.2 Kubernetes / KubeSphere 环境的主从部署在生产 Kubernetes 环境里搭 MGR比 Docker 又难一个维度。Kubernetes 的 Pod 天然是“临时资产”IP 不固定节点重启会换地址Pod 漂移会让 MGR 的成员列表彻底失效。目前最好的实践是使用 StatefulSet 部署保证每个 Pod 拥有稳定的网络标识比如 mysql-0.mysql-mgr.namespace.svc.cluster.local。group_replication_local_address 用 Pod 的域名而非 IPgroup_replication_group_seeds 写成三个 Pod 的完整域名列表。使用 headless Service 配合 ClusterIP 访问让业务连接保持稳定。使用持久化卷保存 /var/lib/mysql避免 Pod 重建后数据丢失。KubeSphere 的应用商店里有很多 MySQL 相关 Helm Chart但多数是传统主从或单实例不一定是 MGR。如果你在 KubeSphere 里点了“部署 MySQL”先看部署模板里有没有 group_replication_* 相关参数没有的话说明它只是“有主从关系的普通复制”不是组复制。真想在企业容器平台跑 MGR要么自己按 StatefulSet 写模板要么直接上 MySQL Operator让 Operator 管理 MGR/InnoDB Cluster 生命周期省得自己天天盯成员状态。在容器环境里尤其要注意健康检查的探针写法。MGR 节点不是所有状态都能对外提供写服务比如 RECOVERING 期间还不应该接业务流量探针里不能只检查 TCP 3306 是否通更稳妥的方式是执行SELECT member_state FROM performance_schema.replication_group_members WHERE member_host hostname;只有返回 ONLINE 时才代表节点真正可用。回到最开始的问题8.4.7 上做“主从搭建”组复制是性价比很高的方案。但 MGR 不是那种“配好参数就躺着不管”的东西节点退出、网络分区、恢复顺序都需要规范和演练。我个人在部署完这套三节点后把自动加入、退出动作、强制恢复流程都沉淀成了文档宁可一开始麻烦一点也比半夜收到告警后再手忙脚乱好得多。如果你正准备搭记得先把业务表主键规范、防火墙端口、复制账号权限这三件事提前确认剩下的大半问题基本都能避免。