performance_schema.replication_group_members是唯一可信的集群成员状态视图，MEMBER_STATE=ONLINE才真正可用；RECOVERING可能卡住；ERROR/UNREACHABLE表示已被驱逐；OFFLINE说明插件未启动。
查 performance_schema.replication_group_members 确认真实状态
这张表是唯一可信的集群成员视图，其他方式（如 SHOW STATUS LIKE 'group_replication%' 或旧版 information_schema.GROUP_REPLICATION_MEMBERS）在节点已失联但尚未被踢出时可能返回空或陈旧数据。
MEMBER_STATE 字段决定一切：ONLINE 才算真正可用；RECOVERING 表示还在同步但可能卡住；ERROR 或 UNREACHABLE 说明已被驱逐；OFFLINE 意味着插件根本没启动。
-
MEMBER_ROLE在单主模式下只有PRIMARY和SECONDARY，不能靠它判断是否可写——即使角色是PRIMARY，只要MEMBER_STATE ≠ ONLINE，写入请求仍会被拒绝 -
MEMBER_VERSION必须与其他节点一致，比如8.0.45节点加入8.0.43组会卡在RECOVERING，不报错但也不前进 - 别查
replication_group_member_stats做离线判断——它只反映本节点本地缓存，断连后容易卡死、返回 NULL 或陈旧值
立刻检查 error.log 中 "gcs: timeout while waiting for message"
这条日志是 GCS 层心跳中断的明确信号，比 MEMBER_STATE = ERROR 出现得更早、更底层。它一出现，就说明组通信通道已经断裂，不是应用层连接问题，而是底层 Paxos 投票机制失效的前兆。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 不要等状态变
ERROR再查日志，高频出现该错误时，MEMBER_STATE很快就会从UNREACHABLE变成ERROR - 重点看错误时间戳是否密集（例如 5 分钟内出现 10+ 次），这基本锁定网络抖动或 DNS 卡顿
- 若日志里同时出现
MY-011582（连接 donor 失败）或MY-011499（成员被移除），说明驱逐已完成，需回溯前面的心跳中断原因
验证 skip_name_resolve 和 group_replication_local_address 配置
DNS 解析卡顿和地址解析错误是触发 GCS 超时最常见的两个配置坑，且都静默发生，不报错但直接导致心跳失败。
- 所有节点必须设
skip_name_resolve = ON，否则 MySQL 启动时或 GCS 建连阶段做反向 DNS 查询，一次超时就足以让心跳中断 -
loose-group_replication_local_address必须用静态 IP + 端口（如"192.168.164.30:33061"），绝不能写localhost、127.0.0.1或域名——MGR 的恢复通道和组通信通道都依赖这个地址对外宣告，写错等于自断手脚 - 用
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'skip_name_resolve';和SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'group_replication_local_address';实时确认，别只信配置文件
用 mtr 探测丢包率与 RTT 抖动
单纯 ping 或 telnet 通不代表 MGR 能稳定运行。Paxos 投票对网络质量极度敏感，丢包率或 RTT 标准差超标会直接导致多数派无法达成共识。
- 执行
mtr --report -c 100，重点关注两列：Loss%> 0.5% 或StDev（RTT 标准差）> 20ms 就危险 - 如果跨机房或云厂商 VPC，还要检查安全组是否放行
33061端口（GCS 默认端口），防火墙拦截往往表现为“无响应”而非“拒绝”，mtr的最后一跳常卡在中间设备 -
group_replication_unreachable_majority_timeout若为 0（默认值），意味着任何一次瞬断都会立即驱逐——这不是 bug，是设计使然；网络不稳时务必调大该值，比如设为 30
真正麻烦的不是节点变 ERROR，而是卡在 RECOVERING 且日志沉默。这时候 caching_sha2_password 认证失败、磁盘满、donor 不可用、甚至 MEMBER_VERSION 小版本不兼容，都可能让它既不报错也不推进。盯紧 performance_schema.replication_group_members 里该行记录的最后更新时间，超过 30 秒没变化，就得手动介入了。
