mgr集群中节点异常时会自动设super_read_only=on且不可手动关闭，真正原因需查performance_schema.replication_group_members中member_state和member_role，而非仅看变量值。
检查 super_read_only 和 read_only 是否被MGR自动置位
MGR集群中，节点状态异常时会强制开启 super_read_only=ON，且该值无法通过 SET GLOBAL super_read_only = OFF 手动关闭——这是MGR的保护机制，不是配置遗漏或权限问题。直接查变量只能看到表象：SELECT @@global.super_read_only, @@global.read_only; 返回 1, 1 很可能只是结果，不是原因。
真正要盯的是集群成员状态：SELECT * FROM performance_schema.replication_group_members; 关键看 MEMBER_STATE 是否为 ONLINE，MEMBER_ROLE 是否仍为 PRIMARY（或 SECONDARY）。若出现 RECOVERING、ERROR、UNREACHABLE 或空行，说明该节点已脱离共识，MGR自动锁死写入。
- 只要集群未达成多数派（
majority），所有节点都会被强制设为super_read_only=ON -
super_read_only被MGR控制时，即使你用root执行SET GLOBAL super_read_only = OFF，MySQL也会立即回滚该值并报错ERROR 1238 (HY000): Variable 'super_read_only' is a read only variable - 不要在
my.cnf里硬写super_read_only=OFF—— MGR启动后会覆盖它
确认集群是否丢失多数派（majority）
MGR要求至少 ⌈n/2⌉+1 个节点在线才能接受写入。三节点集群挂掉一个还能写；挂掉两个，剩下那个立刻只读，且无法自行恢复。错误日志里典型线索是：[ERROR] [MY-011582] Plugin group_replication reported: 'There was an error when connecting to the donor server' 或更关键的：[ERROR] [MY-011583] Local transaction set: 后面跟着空集或不完整GTID集合。
执行：SELECT * FROM performance_schema.replication_group_member_stats\G，重点看 COUNT_TRANSACTIONS_IN_QUEUE 和 COUNT_TRANSACTIONS_CHECKED。如果前者持续增长、后者长期为 0，基本可判定节点卡在认证队列，无法参与Paxos投票。
- 网络分区（如防火墙临时拦截
33061端口）比机器宕机更容易触发“逻辑性多数丢失” - 检查节点间时间同步：
timedatectl status，MGR对时钟偏移敏感，>500ms 可能导致心跳误判 - 别依赖
ping：MGR走的是专用端口（默认33061），必须用nc -zv mgr-node2 33061实测连通性
识别 ERROR 3099 (HY000) 类错误是否已实际发生
ERROR 3099 (HY000): The transaction cannot be certified because the group has lost the majority 不是警告，是写入已被拒绝的明确信号。它通常出现在客户端报错里，但服务端日志可能只记一行 [Warning] [MY-011499] Plugin group_replication reported: 'Members removed from the group: ...'，容易被忽略。
查日志不能只翻 error.log，要配合：grep -i "group_replication\|3099\|3098" /var/log/mysql/error.log | tail -50。特别注意时间戳是否密集出现——连续几秒内刷出 5+ 条同类警告，基本说明集群已分裂，当前节点是孤岛。
- 该错误一旦出现，意味着最近的事务已无法通过Paxos认证，后续所有写入都会失败，直到集群重聚
-
ERROR 3098 (HY000)（表不满足MGR要求）常与3099并发出现，但它是前置条件：比如某张表没主键、引擎非InnoDB，会导致事务根本进不了认证队列 - 别急着重启：若节点处于
RECOVERING状态，重启只会让它重新卡住；先用STOP GROUP_REPLICATION;再START GROUP_REPLICATION;尝试软恢复
验证文件系统和磁盘空间是否叠加触发只读
MGR节点进入只读后，很多人只盯着集群状态，却忘了底层资源告警也会触发同一表现。例如：df -h /var/lib/mysql 显示 100% 使用率，MySQL会先自我保护设 read_only=ON，此时即使MGR集群健康，写入也依然失败。
检查顺序必须是：先看磁盘 → 再看MGR状态 → 最后看变量。因为磁盘满导致的 read_only=ON 是全局生效的，而MGR触发的 super_read_only=ON 是协议层行为，两者共存时日志里可能混杂两种线索。
- 清理磁盘后，必须执行
SET GLOBAL read_only = OFF;（仅对磁盘触发有效），但super_read_only仍需靠MGR自动恢复 - 检查
/var/lib/mysql所在分区的挂载选项：mount | grep mysql，确认不是ro（只读挂载）——这种情况下连SET命令都会报错 - 若使用LVM或云盘，注意
lvdisplay或云平台控制台的“卷状态”，某些存储故障表现为IO hang而非空间满，也会诱使MySQL降级为只读
