MySQL 8.4 LTS 的 Group Replication 必须显式配置5个核心参数并重启生效：server_id、gtid_mode=ON且enforce_gtid_consistency=ON、binlog_format=ROW、log_bin与log_slave_updates=ON、group_replication_group_name（UUID格式），缺一将导致START GROUP_REPLICATION失败或卡在RECOVERING状态。
MySQL 8.4 LTS 的 Group Replication 参数不能靠“开插件就完事”，必须显式配置关键参数并重启生效，否则 START GROUP_REPLICATION 会直接报错或卡在 RECOVERING 状态。
必须显式配置的 5 个核心参数
MySQL 8.4 默认不启用 MGR，group_replication 插件本身是禁用的，且多数控制参数无合理默认值。以下 5 项必须写入 my.cnf 的 [mysqld] 段并重启：
-
server_id：每个节点唯一，不能为 0 或重复（例如server_id = 101） -
gtid_mode = ON且enforce_gtid_consistency = ON：MGR 强制依赖 GTID，缺一不可 -
binlog_format = ROW：仅支持基于行的日志，STATEMENT或MIXED会导致成员加入失败 -
log_bin和log_slave_updates = ON：主库和副本都需开启二进制日志并记录中继日志变更 -
group_replication_group_name：UUID 格式（如aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa），所有节点必须完全一致
group_replication_local_address 和 group_replication_group_seeds 怎么填
这两个地址参数决定节点能否互相发现和握手，填错会导致集群无法形成或反复断连：
-
group_replication_local_address是本机对外暴露的 IP:PORT（不是127.0.0.1），必须能被其他节点直连；云环境注意安全组放行该端口（默认33061） -
group_replication_group_seeds是初始引导节点列表，格式为ip1:port1,ip2:port2，至少包含一个当前节点自身（用于单节点启动）；首次部署建议全写上所有节点地址，避免冷启动失败 - 若使用 Docker 或 Kubernetes，不要用
localhost或容器 hostname，而应填宿主机可路由的 IP 或 Service DNS 名（如mysql-node-0.mysql.svc.cluster.local:33061）
group_replication_consistency 设成 BEFORE_ON_PRIMARY_FAILOVER 会卡住吗
会，但这是预期行为——不是故障，而是强一致性保障的代价：
- 该参数在 MySQL 8.4 中默认启用，意味着 Primary 切换前，新主必须回放完所有已提交事务的 binlog；若存在大事务或网络延迟，切换耗时可能从几十毫秒升至数秒
- 应用连接 MySQL Router 时，若超时时间设得太短（如
connect_timeout=2），可能在切换窗口内收到Lost connection或Timeout during primary election - 它只影响故障转移过程，不影响日常读写；若业务能接受短暂最终一致性（如报表类查询），可降级为
EVENTUAL，但必须在my.cnf中显式配置并重启，SET GLOBAL不生效
容易忽略的权限与插件加载顺序
即使参数全对，START GROUP_REPLICATION 仍可能报 ERROR 3092 (HY000) 或认证失败，常见原因有：
- 执行用户缺少
GROUP_REPLICATION_ADMIN权限（不是REPLICATION SLAVE）：运行GRANT GROUP_REPLICATION_ADMIN ON *.* TO 'repl'@'%'; -
group_replication插件未正确加载：检查SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'group_replication';返回ACTIVE，否则需先INSTALL PLUGIN group_replication SONAME 'group_replication.so'; - MySQL 8.4 默认禁用
mysql_native_password，如果复制账户用该插件认证（旧脚本常见），需在CREATE USER时显式指定IDENTIFIED WITH caching_sha2_password，否则握手失败
真正麻烦的从来不是参数名记不住，而是某台节点漏配了 log_slave_updates，或者云服务器安全组只开了 3306 却忘了放行 33061 —— 这类问题不会报明确错误，只会让节点永远停在 RECOVERING 状态，查日志也只看到“waiting for view change”。
