如何判断当前MGR集群是单主还是多主模式
直接查 performance_schema.replication_group_members 和 performance_schema.global_status 里的关键状态值。单主模式下，只有一个是 PRIMARY 角色，其余全是 SECONDARY；多主模式下，所有成员角色都是 PRIMARY —— 但注意，这不等于“所有节点都可写”，还要看 group_replication_single_primary_mode 变量是否为 ON。
实操建议：
- 运行
SELECT * FROM performance_schema.replication_group_members;，看MEMBER_ROLE列 - 运行
SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'group_replication_single_primary_mode';，结果为ON表示强制单主，OFF才可能启用多主 - 别只信
MEMBER_ROLE，MySQL 8.0.27+ 在单主模式下也会把非主节点显示为PRIMARY（这是 bug 行为），必须结合变量值判断
启动时配置单主或多主的关键参数组合
MGR 启动后不能动态切换单/多主模式，必须重启实例并确保配置一致。核心就两个变量：group_replication_single_primary_mode 和 group_replication_enforce_update_everywhere_checks，它们的组合决定行为。
实操建议：
- 单主模式：设
group_replication_single_primary_mode=ON，group_replication_enforce_update_everywhere_checks=OFF（默认） - 多主模式：设
group_replication_single_primary_mode=OFF，且group_replication_enforce_update_everywhere_checks=ON（必须显式开启） - 漏配
enforce_update_everywhere_checks=ON会导致多主启动失败，报错ERROR 3092 (HY000): The server is not configured properly to be an active member of the group - 所有节点的这两个变量值必须完全一致，否则加入集群会被拒绝
角色切换不是“手动指定”，而是由选举触发
MGR 没有类似 SET GLOBAL group_replication_primary_member 这种命令。主节点故障或主动退出时，剩余节点自动发起选举，新主由 group_replication_member_expel_timeout 和 group_replication_autorejoin_tries 等参数影响恢复节奏，但选举逻辑本身不可干预。
实操建议：
- 想让某节点大概率当选新主？提前把它设为
group_replication_member_weight=100（其他设为 50 或更低），权重高者优先 - 单主模式下，原主恢复后不会抢回主角色，仍以只读方式加入，除非手动执行
STOP GROUP_REPLICATION; START GROUP_REPLICATION;—— 但这会触发新一轮选举，不一定赢 - 多主模式下不存在“主从切换”概念，所有节点本就可写，但冲突检测（基于事务哈希）会让后提交的冲突事务回滚，日志里出现
ER_GRP_RPL_CONFLICT_DETECTED
为什么改了配置却没生效？常见卡点
最常踩的坑不是参数写错，而是配置未在正确位置加载、或被运行时值覆盖。MGR 对配置一致性极其敏感，一个节点掉队就可能全组阻塞。
实操建议：
- 确认配置写在
my.cnf的[mysqld]段，且 MySQL 启动时实际加载了该文件（用mysql --help | grep "Default options"验证路径） - 检查是否误在运行时 SET 全局变量（如
SET PERSIST group_replication_single_primary_mode=OFF），这不会生效 —— MGR 相关变量**不支持 PERSIST**，必须写配置文件再重启 - 启用了 SELinux 或 AppArmor？常见报错
Failed to open log file: Permission denied会静默阻止 MGR 启动，看似配置对了但集群起不来 - 防火墙挡住
group_replication_local_address端口（默认 33061），节点间无法握手，performance_schema.replication_group_members里只显示自己
真正麻烦的是跨版本升级后的行为变化，比如 8.0.23+ 对多主冲突检测更严格，老应用没处理 ER_GRP_RPL_CONFLICT_DETECTED 就会卡住。这种细节，文档里往往藏得很深。
