single-primary模式下写操作仅限primary节点，故障切换需几秒且应用需处理中断；multi-primary虽允许多点写入但冲突率高、延迟敏感，跨机房部署推荐single-primary。
single-primary 模式下写操作只能落在一个节点，group_replication_single_primary_mode 必须设为 ON
这是 MySQL Group Replication 的默认模式，也是生产环境最常选的。所有写事务只允许在 primary 节点执行，其他节点自动降为 secondary（只读）。一旦 primary 故障，组内会自动选新 primary，但这个过程需要几秒——期间写入会失败，应用得处理连接中断或重试。
常见错误现象：ERROR 1290 (HY000): The MySQL server is running with the --read-only option，其实是应用误连 secondary 节点发了 INSERT/UPDATE；或者没配置 group_replication_consistency 导致主从间短暂不一致，读到旧数据。
- 必须显式设置
group_replication_single_primary_mode=ON，否则可能因版本或启动顺序意外进入 multi-primary - 应用层要区分读写连接：写固定打 primary（可通过
SELECT @@group_replication_primary_member查），读可负载均衡到任意节点 -
group_replication_consistency建议设为BEFORE_ON_PRIMARY_FAILOVER或更高，避免 failover 后读到 gap - 不要依赖
read_only=OFF判断是否可写——Group Replication 会强制覆盖该变量，只认内部角色
multi-primary 模式允许所有节点写，但冲突检测开销大、应用改造成本高
所有节点都可接受写请求，MySQL 用 certification-based replication 做冲突检测：事务提交前检查其修改的行是否被其他节点并发修改过。冲突则回滚后端事务，返回 ER_GR_APPLIER_APPLY_EVENT_PREVIOUS_GTID_ERROR 类错误。
典型踩坑场景：同一张表的两个节点同时更新同一行（哪怕只是 UPDATE counter += 1），必然冲突；或者业务没做幂等，重试时重复插入；再或者未禁用 autocommit=0 下的隐式事务，导致认证范围扩大、性能骤降。
- 必须全局关闭
group_replication_enforce_update_everywhere_checks=OFF才能启用 multi-primary，否则启动直接报错 - 所有节点的 schema、表引擎（必须是 InnoDB）、字符集、SQL mode 必须完全一致，否则认证失败概率飙升
- 禁止使用非确定性函数（
NOW()、UUID()、@@server_uuid等），否则事务无法通过认证 - 写吞吐不会线性提升——冲突越多，回滚越频繁，实际性能可能比 single-primary 还低
跨机房部署时，single-primary 更可控，multi-primary 容易因网络延迟放大冲突
Group Replication 的认证过程依赖 GTID 和 binlog event 的全量广播，节点间 RTT 超过 50ms 就明显拖慢事务提交。multi-primary 下每个写节点都要等其他节点的认证反馈，延迟直接叠加；而 single-primary 只需 primary 和下游同步，secondary 延迟不影响写入路径。
真实案例：某金融客户把三个节点分在北上深，启用 multi-primary 后日均冲突率超 12%，核心账务服务频繁报错；切回 single-primary 并将 primary 固定在上海，冲突归零，平均写入延迟稳定在 8ms 内。
- 跨地域部署强烈建议用 single-primary，并把 primary 放在延迟最低、带宽最高的中心机房
- multi-primary 不适合地理分散节点——不是“能不能跑”，而是“能不能稳住业务逻辑”
- 如果真要多活，优先考虑应用层分片 + 单 region single-primary，而非依赖 MySQL 层 multi-primary
切换模式不是改个参数重启就行，必须停写、清空 group_replication_group_name、重新引导组
MySQL 不支持运行中切换 group_replication_single_primary_mode。强行改参数并 STOP GROUP_REPLICATION; START GROUP_REPLICATION; 会导致组分裂或节点拒绝加入，错误信息通常是 ERROR 3092 (HY000): The server is not configured properly to be an active member of the group。
真正安全的操作路径是：所有节点停写 → 每个节点执行 RESET MASTER 和 SET GLOBAL group_replication_group_name = '00000000-0000-0000-0000-000000000000' → 按新模式顺序引导第一个节点（START GROUP_REPLICATION）→ 其他节点依次加入。
- 切换前务必备份 binlog 和数据，multi-primary 切 single-primary 时可能丢掉未认证的本地写入
- 不要跳过
RESET MASTER——残留的 GTID set 会干扰新组初始化 - 第一个节点启动后，必须等
SELECT * FROM performance_schema.replication_group_members显示状态为ONLINE，再加第二个
业务上没那么多“既要又要”。single-primary 是多数场景的务实选择，multi-primary 是特定架构下的权衡，不是升级选项。真正难的从来不是配参数，而是想清楚：你的应用能不能容忍写失败、能不能处理冲突回滚、有没有能力做读写分离路由——这些比模式本身更决定成败。
