MySQL 8.0 MGR默认单主模式，必须显式关闭group_replication_single_primary_mode=OFF并启用enforce_update_everywhere_checks=ON才能多点写入，否则其余节点自动设为super_read_only=ON。
MySQL 8.0 的 Group Replication（MGR）本身不等于“多活”，它只是实现多活的底层能力之一；真正能对外提供多节点读写能力，必须开启多主模式并绕过默认的只读限制——否则即使插件跑起来了，其他节点也自动被设为 super_read_only=ON，根本没法写。
为什么装完 group_replication 插件后还是只能单点写？
因为默认是单主模式，group_replication_single_primary_mode=ON。这个参数一开，MGR 就会强制把除主节点外的所有成员设为只读，哪怕你没手动执行 SET GLOBAL super_read_only=ON，它也会悄悄帮你加上。
- 必须显式关闭：在每个节点的配置文件里加
loose-group_replication_single_primary_mode=OFF - 配套打开冲突检查：加
loose-group_replication_enforce_update_everywhere_checks=ON，否则多主写入时事务认证直接失败 - 启动前确认：执行
SELECT @@super_read_only，值必须是0才算生效；如果仍是1，说明配置没加载或插件没重载
多主模式下哪些 SQL 会静默失败或引发认证冲突？
MGR 多主靠 write-set 做并发控制，但不是所有语句都能被正确提取写集——遇到非确定性函数、隐式类型转换、无主键表，就会丢写集或产生冲突，最终导致事务被拒绝。
-
NOW()、UUID()、SYSDATE()这类函数在不同节点生成不同值，写集无法比对，建议改用CURRENT_TIMESTAMP或应用层生成时间戳 - 没有主键或唯一键的表，MGR 无法定位行变更，
UPDATE/DELETE会被拒绝，错误日志里出现Transaction cannot be certified - 跨库 JOIN 写操作（如
UPDATE db1.t1 JOIN db2.t2）不被 write-set 支持，会报错退出
Windows 11 下部署 MGR 多主最容易漏掉的三件事
Windows 环境下不光要配 MySQL 参数，系统级和网络层的约束更隐蔽，稍不注意就卡在 RECOVERING 状态不动。
-
disabled_storage_engines必须完整列出："MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"，少一个（比如漏掉MEMORY），INSTALL PLUGIN group_replication直接失败，且错误提示极不明确 - Windows 防火墙默认拦掉
33060端口（MGR 通信端口），仅开放3306不够；要用New-NetFirewallRule显式放行，不能只依赖“允许应用通过防火墙”图形界面 -
loose-group_replication_local_address值必须和my.ini中绑定的网卡 IP 一致，Windows 多网卡常见，若填了127.0.0.1或 WSL2 虚拟网卡地址，节点间握手会超时，performance_schema 表里MEMBER_STATE永远卡在OFFLINE
多主模式不是开个开关就能稳跑的架构，它把一致性校验从复制层前置到了事务提交前——这意味着你写的每条 SQL 都可能被拦截，而错误往往不抛到客户端，只记在 error log 最后几行。上线前务必用真实业务语句压测，尤其关注含时间函数、JOIN、无主键表的操作是否被静默拒绝。
