MySQL 8.0+ 必须开启 binlog 和 GTID
组复制（MGR）不是插件式可选功能，它底层强依赖 binlog 和 gtid_mode=ON。不满足这两点，START GROUP_REPLICATION 会直接报错 ER_GROUP_REPLICATION_CONFIGURATION_ERROR。
-
log_bin必须为 ON，且binlog_format只能是ROW（MGR 不支持 STATEMENT 或 MIXED） -
gtid_mode=ON+enforce_gtid_consistency=ON是硬性要求，哪怕你只打算用单主模式 - 如果实例已有数据，开启 GTID 前必须确保所有事务都已刷盘、无正在执行的非 GTID 兼容操作（比如带
CREATE TEMPORARY TABLE的事务）
my.cnf 里 mgr 相关配置不能只写一半
常见错误是只配了 group_replication_group_name，却漏掉 group_replication_local_address 或 group_replication_group_seeds，导致节点启动后卡在 RECOVERING 状态，日志反复打印 Waiting for members to join group。
-
group_replication_local_address必须是其他节点能直连的 IP:PORT（比如192.168.10.11:33061），不能写localhost或127.0.0.1 -
group_replication_group_seeds是初始引导地址列表，格式为"ip1:port1,ip2:port2"，必须包含自己（否则首次启动失败），且所有节点该值要一致 -
group_replication_bootstrap_group=OFF—— 只有第一个节点启动时临时设为ON，之后立即设回OFF，否则重启后会脑裂
启动顺序和用户权限容易被忽略
MGR 要求每个节点上存在专用复制用户，并且该用户必须有 GROUP_REPLICATION_ADMIN 权限。没授权或密码不一致，START GROUP_REPLICATION 会报 ER_ACCESS_DENIED_ERROR 或卡住不动。
- 先在每个节点执行：
CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';<br>GRANT GROUP_REPLICATION_ADMIN ON *.* TO 'repl'@'%';
- 然后设置复制通道凭据：
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='xxx' FOR CHANNEL 'group_replication_recovery'; - 第一个节点执行
SET GLOBAL group_replication_bootstrap_group=ON;后再START GROUP_REPLICATION，完成后立刻SET GLOBAL group_replication_bootstrap_group=OFF;
单主模式下写节点故障转移不自动
很多人以为 MGR 单主模式会像 Pacemaker 那样自动选新主，其实不会。原主宕机后，集群状态变成 ERROR 或 UNREACHABLE，剩余节点仍为只读，需要人工干预。
- 确认原主彻底离线后，在一个健康节点上执行：
SELECT group_replication_set_as_primary('uuid-of-new-primary'); - UUID 要从
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'server_uuid';查，不能手敲 - 如果启用了
group_replication_autorejoin_tries（默认 0），可以设为非零值让节点断连后自动重试加入，但无法替代主节点切换逻辑
真正麻烦的是应用层：连接池、读写分离中间件是否感知节点角色变化？MGR 本身不提供 VIP 或 DNS 切换能力，这部分得自己兜底。
