MGR不是“配完就能跑”的复制方案，必须严格满足GTID启用、ROW格式、XXHASH64写集提取、禁用非InnoDB引擎、log_slave_updates开启五项硬性条件，缺一则插件加载失败或同步中断。
直接上结论：MGR不是“配完就能跑”的复制方案，group_replication 插件必须配合 GTID、ROW 格式、write-set 提取、禁用非 InnoDB 引擎等硬性条件，缺一不可；否则启动失败或同步静默中断。
MySQL 8.0 启动前必须确认的 5 项基础配置
这些不是可选项，是 group_replication 插件加载和组通信的前置门槛：
-
gtid_mode=ON且enforce_gtid_consistency=ON—— MGR 依赖 GTID 做事务追踪和冲突检测，关闭即报错 -
binlog_format=ROW—— STATEMENT 或 MIXED 模式下group_replication无法加载，日志里会明确提示Plugin 'group_replication' init function returned error -
transaction_write_set_extraction=XXHASH64—— 不设或设错（如设成XXHASH32）会导致节点加入后无法认证写集，状态卡在RECOVERING -
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"—— MGR 只支持 InnoDB 表，漏掉任意一个引擎都会在插件初始化时报错 -
log_slave_updates=ON—— 即使是单主模式，所有节点也必须开启，否则从节点无法将接收到的组内事务写入自己的 binlog，导致后续节点无法追平
group_replication_group_name 必须是合法 UUID 格式
这个参数看着像字符串，实则是强校验字段。填错会导致节点拒绝加入组，错误信息藏在错误日志里：Group replication: Invalid group name format。
正确做法是用真实 UUID，别手写或复制示例里的占位符：
- 查本机 UUID：
SELECT UUID();或读/var/lib/mysql/auto.cnf中的server-uuid - 三节点必须完全一致，比如都设为
"a1b2c3d4-5678-90ab-cdef-1234567890ab" - 不能带空格、中文、下划线，也不能少位数（必须是 32 字符 + 4 个短横）
group_replication_local_address 和 group_replication_group_seeds 的网络陷阱
这两个地址不是 MySQL 客户端连接地址，而是 MGR 内部组通信端口（默认 :33061），常被防火墙或 Docker 网络拦住。
-
group_replication_local_address必须填节点**能被其他节点直连的 IP+端口**，比如 Docker 容器要用宿主机可路由的 IP，不能填127.0.0.1或容器内部网段 IP -
group_replication_group_seeds是引导列表，每个地址格式同上，且必须包含所有节点的local_address，顺序无关，但少一个就可能造成新节点无法发现集群 - 常见现象：节点状态长期卡在
OFFLINE，SHOW STATUS LIKE 'group_replication%';显示group_replication_communication_stack为空，基本就是通信端口不通
启动顺序和 bootstrap_group 的危险操作
MGR 不是所有节点一起 start 就能自动组网。第一个节点必须显式引导，后续节点只能加入 —— 错误地对非首个节点执行 bootstrap 会分裂集群。
- 仅在**第一个节点**执行：
SET GLOBAL group_replication_bootstrap_group=ON;→START GROUP_REPLICATION;→SET GLOBAL group_replication_bootstrap_group=OFF; - 其余节点只执行：
START GROUP_REPLICATION;，不碰bootstrap_group - 如果误操作导致脑裂（比如两个节点都 bootstrapped），必须手动清理：
STOP GROUP_REPLICATION;+ 删除mysql.group_replication_recovery表相关记录 + 重置 GTID set
最容易被忽略的是：MGR 节点间时间不同步超过 5 秒，会导致心跳超时、频繁驱逐成员；而 loose-group_replication_recovery_retry_count 默认值极小（MySQL 8.0.22 前是 10），网络抖动一次就可能让节点永久掉线 —— 生产环境务必调大并配 NTP 同步。
