必须配置server_id、gtid_mode=ON、enforce_gtid_consistency=ON、log_bin=binlog、binlog_format=ROW、log_slave_updates=ON、master_info_repository=TABLE、relay_log_info_repository=TABLE、binlog_checksum=NONE及loose-group_replication_local_address等参数，缺一不可且不可用默认值。
server_id 必须全局唯一，gtid_mode=ON 和 enforce_gtid_consistency=ON 是硬性前提，否则 group_replication 插件加载后无法启动。
my.cnf 里哪些参数不能漏、不能错
单主模式不是“开了插件就行”，底层依赖 GTID 和事务日志的强一致性保障。以下参数在所有节点的 /etc/my.cnf 中必须显式配置，且多数不可用默认值：
-
server_id：每台机器必须不同（如128、130、131），不能是 0 或重复 -
gtid_mode=ON+enforce_gtid_consistency=ON：缺一不可，否则START GROUP_REPLICATION会报错ERROR 3092 (HY000): The server is not configured properly to be an active member of the group -
log_bin=binlog+binlog_format=ROW：MGR 只支持 ROW 格式，STATEMENT或MIXED会导致组内事务拒绝加入 -
log_slave_updates=ON：从节点也要写 binlog，否则新主选举后无法继续向下游同步 -
master_info_repository=TABLE和relay_log_info_repository=TABLE：元数据必须存表，文件方式不支持组复制的原子性恢复 -
binlog_checksum=NONE：MySQL 5.7.17–8.0.22 期间，开启 checksum 会导致组内消息校验失败，直接卡在RECOVERING状态
loose-group_replication_local_address 怎么填才不连不上
这个地址是节点间 P2P 通信用的，不是 MySQL 客户端连接地址。填错会导致成员状态长期卡在 RECOVERING 或直接 OFFLINE：
- 必须是节点能互相直连的 IP（不能填
127.0.0.1或localhost） - 端口建议避开常用服务（如 3306、33060），官方推荐用
10086或33061，三台机器保持一致 - 确认防火墙放行该端口：
firewall-cmd --permanent --add-port=10086/tcp，然后firewall-cmd --reload - 检查 SELinux 是否拦截：
setsebool -P mysql_connect_any on（CentOS 7 默认启用）
启动顺序和权限设置容易踩的坑
插件加载、用户创建、组启动三步有严格依赖，顺序错一步整个集群就起不来：
- 先在所有节点执行：
INSTALL PLUGIN group_replication SONAME 'group_replication.so';，注意不是LOAD PLUGIN - 复制账号必须带
REPLICATION SLAVE和REPLICATION CLIENT权限，且 host 不能是%（MGR 要求显式授权）：CREATE USER 'repl'@'192.168.88.%' IDENTIFIED BY 'pass123'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.88.%'; - 主节点先执行：
SET GLOBAL group_replication_bootstrap_group=ON;→START GROUP_REPLICATION;→ 再立即SET GLOBAL group_replication_bootstrap_group=OFF;（不关会导致下次重启脑裂） - 从节点只执行：
START GROUP_REPLICATION;，不要设bootstrap_group
验证集群状态时看哪几个关键字段
别只看 SELECT * FROM performance_schema.replication_group_members; 的 MEMBER_STATE，这三个字段才是真实状态：
-
MEMBER_STATE = ONLINE：只是网络可达，不代表数据已同步 -
MEMBER_ROLE = PRIMARY或SECONDARY：确认角色是否符合预期 -
MEMBER_VERSION：版本不一致（比如混用 8.0.22 和 8.0.33）会导致部分节点反复ERROR然后退出组 - 真正判断同步是否就绪，查
SELECT * FROM performance_schema.replication_group_member_stats\G，重点关注COUNT_TRANSACTIONS_IN_QUEUE和COUNT_TRANSACTIONS_CHECKED是否为 0
实际部署中最容易被忽略的是 binlog_checksum=NONE 这个开关——它在 MySQL 8.0.23+ 才默认关闭，但当前主流生产环境仍大量使用 8.0.22 及更早版本，漏掉这一项，集群永远卡在 RECOVERING。
