如何配置MySQL 8.0组复制MGR实现高可用架构？

MySQL 8.0 Group Replication 插件运行需满足五项硬性配置：① gtid_mode=ON 且 enforce_gtid_consistency=ON；② binlog_format=ROW；③ transaction_write_set_extraction=XXHASH64；④ disabled_storage_engines 禁用非 InnoDB 引擎；⑤ log_slave_updates=ON，且 group_replication_local_address 与 group_name（UUID v4）须正确配置。

MySQL 8.0 的 group_replication 插件不是“改完配置 reload 就能跑”的复制方案——它对实例基础配置有五项硬性要求，缺一就会卡在 OFFLINE 或 RECOVERING 状态，甚至静默失败。

gtid_mode=ON 且 enforce_gtid_consistency=ON 必须同时生效

MGR 依赖 GTID 做事务唯一标识和冲突检测，关闭任一都会导致插件初始化报错：Plugin 'group_replication' init function returned error。即使只用单主模式，也不能设为 OFF 或 ON_PERMISSIVE；必须是 ON，且 enforce_gtid_consistency 也得是 ON。这两项必须写进 my.cnf 并重启 mysqld，SET GLOBAL 动态修改无效。

binlog_format=ROW 是强制前提，不是可选项

group_replication 只支持 ROW 格式，因为写集（write-set）提取依赖行级变更记录。设成 MIXED 或 STATEMENT 时，插件加载直接失败，错误日志明确提示：Group Replication requires binlog_format = ROW。建议同时开启：binlog_transaction_dependency_tracking=WRITESET，提升并发事务认证效率。注意：已有表若含 NOW()、UUID() 等非确定性函数，在 ROW 模式下仍可能引发复制异常，需提前评估或改用 SYSDATE() 等替代。

transaction_write_set_extraction=XXHASH64 必须显式指定

这个参数控制写集哈希算法，MGR 要求严格使用 XXHASH64。不设、设空、或设成 XXHASH32/XXHASH128，节点加入组后会卡在 RECOVERING 状态，无法完成认证。日志中不会直接报错，但 performance_schema.replication_group_members 中 MEMBER_STATE 长期不变成 ONLINE。它和 binlog_transaction_dependency_tracking 是两个独立参数，不能互相替代。

disabled_storage_engines 必须禁用全部非 InnoDB 引擎

MGR 只允许 InnoDB 表参与复制，漏掉任意一个引擎都会在插件启动阶段报错：Plugin 'group_replication' registration failed，日志里紧跟着提示某引擎未被禁用。正确值示例：disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"。注意大小写敏感，英文逗号分隔，不能有空格或换行。如果实例中已存在 MyISAM 表，INSTALL PLUGIN group_replication 会失败，得先转换表或清空。

log_slave_updates=ON 所有节点都必须开启

即使是单主模式，所有节点（包括未来可能成为主的节点）都必须把 relay log 再写进自己的 binlog。关闭会导致后续节点无法追平——从节点接收到的组内事务不会进入自身 binlog，其他节点就无法基于它继续复制。错误现象是：新节点加入后始终无法同步，SHOW REPLICA STATUS 显示 Seconds_Behind_Master 持续增长，但 performance_schema.replication_applier_status_by_coordinator 无明显积压。

group_replication_local_address 和 hosts 解析必须真实可达

group_replication_local_address 不是 MySQL 客户端连接地址，而是 MGR 内部组通信端口（默认 33061），常被防火墙或 Docker 网络拦住。必须填其他节点能直连的真实 IP + 端口，比如 192.168.10.11:33061，不能填 127.0.0.1 或容器内部网段 IP。每台节点的 /etc/hosts 必须严格一致，IP 与主机名一一对应，不加端口、不加空格、不写注释；三节点必须用不同主机名（如 mgr-node1、mgr-node2、mgr-node3），否则解析失败会导致状态卡死在 RECOVERING。

最容易被忽略的是 group_replication_group_name ——它必须是合法 UUID v4 格式（32 字符 + 4 个短横线），所有节点完全一致。填错不会在启动时报错，但 START GROUP_REPLICATION 会静默失败，performance_schema.replication_group_members 始终为空，错误日志里只提示 This server is not able to reach a majority。