MGR插件启用前须满足五项硬性配置：①gtid_mode与enforce_gtid_consistency必须均为ON；②binlog_format必须为ROW；③transaction_write_set_extraction必须设为XXHASH64；④disabled_storage_engines须禁用非InnoDB引擎；⑤log_slave_updates必须为ON。
group_replication 插件不是“配完 reload 就能跑”的复制方案，它对 MySQL 实例的基础配置有五项硬性要求，缺一就会加载失败、状态卡在 OFFLINE 或同步静默中断。
gtid_mode=ON 和 enforce_gtid_consistency=ON 必须同时启用
MGR 依赖 GTID 做事务唯一标识与冲突检测，关闭任一都会导致插件初始化报错：
- 错误日志典型提示：
Plugin 'group_replication' init function returned error - 即使你只打算用单主模式，也必须开 GTID；MGR 不接受
OFF或ON_PERMISSIVE - 配置后需重启 mysqld，
SET GLOBAL动态修改无效
binlog_format=ROW 是强制前提，不是可选项
MGR 只支持 ROW 格式，因为写集（write-set）提取依赖行级变更记录：
- 设为
MIXED或STATEMENT时，插件加载直接失败，错误日志明确提示：Group Replication requires binlog_format = ROW - 同时建议开启：
binlog_transaction_dependency_tracking=WRITESET，提升并发事务认证效率 - 注意：已有库表若含非确定性函数（如
NOW()、UUID()），在ROW模式下仍可能引发复制异常，需提前评估
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
- 错误现象：新节点状态始终是
RECOVERING，SHOW PROCESSLIST里看不到 SQL 线程在应用 relay log - 这个参数影响的是“组内事务传播链”，不是传统主从里的“是否记录从库执行的 binlog”
group_replication_group_name 必须是合法 UUID，group_replication_local_address 必须可路由，这两点容易被当成“网络配置问题”排查半天，其实根本原因是校验失败或地址不可达。真正卡住 MGR 的，往往不是集群逻辑，而是这五个基础参数里某一个没踩准。
