必须立即停止滚动升级，因5.7与8.0的mgr通信协议（xcom vs mysql栈）不兼容，混用会导致unreachable状态及error 3092，需全部节点升级完毕并校验group_replication_group_name（合法uuid）、loose-group_replication_local_address（可路由真实ip）等参数后，再统一启动组复制。
检查 MEMBER_VERSION 是否混用 5.7 和 8.0
升级单个节点后，SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members; 很可能返回混合版本结果，比如两个 8.0.33 节点和一个 5.7.42 节点。这不是“临时兼容态”，而是协议不互通的明确信号：MySQL 5.7 的 MGR 使用 XCOM 栈，8.0 默认启用 MySQL Group Communication（MYSQL）栈，二者无法协商握手。
此时新升级的 8.0 节点会卡在 UNREACHABLE 或反复报错 ERROR 3092 (HY000): the server is not configured properly to be an active member of the group，但日志里不会直接说“版本不匹配”，只会提示通信失败或配置错误。
- 必须等全部节点都完成升级并重启后，才能执行集群级操作（如
START GROUP_REPLICATION） - 滚动升级时，禁止在 5.7 节点还在运行时，让 8.0 节点尝试加入——它连握手包都发不出去
-
MEMBER_VERSION字段值来自mysqld --version输出，不是靠配置伪装能绕过的
确认 group_replication_group_name 在所有节点是否完全一致
8.0 升级后若沿用旧配置，容易忽略 group_replication_group_name 必须是合法 UUID 格式（如 aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa），且所有节点严格相同。5.7 时期部分运维习惯用短字符串甚至域名当 group name，这在 8.0 中会导致组发现失败，错误日志表现为 Failed to initialize the group communication engine。
检查方式：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'group_replication_group_name';
- 不能含下划线、大写字母、空格或中文
- 长度必须为 36 位（8-4-4-4-12 格式），少一位或多一位都不行
- 修改后需重启 mysqld，仅
SET PERSIST不生效
验证 loose-group_replication_local_address 是否指向可路由真实 IP
这是升级后最常被误配的项。5.7 时代有些环境用 127.0.0.1:33061 也能跑通（依赖 loopback 通信），但 8.0 MGR 默认拒绝 localhost 类地址，且要求该地址必须能被其他节点 telnet 或 nc 直连。
典型错误现象：ERROR 3092 + 日志中出现 Unable to bind to address 或静默无响应。
- 执行
ss -tlnp | grep :33081（端口按你配置替换），确认 mysqld 真正在监听那个 IP:PORT - 从另一节点执行
nc -zv 192.168.150.22 33081，失败说明网络层不通（防火墙/SELinux/多网卡选错） - 不要依赖 hostname 解析；
/etc/hosts中该 hostname 对应的 A 记录必须和loose-group_replication_local_address中写的 IP 完全一致
重置 GTID 状态前先停掉所有写入与复制通道
如果节点已启动但状态为 RECOVERING 或 ERROR，别急着 RESET MASTER。先确保：STOP GROUP_REPLICATION;、STOP SLAVE FOR CHANNEL 'group_replication_recovery';、SET SQL_LOG_BIN = OFF; 全部执行成功。
否则 RESET MASTER 会清空 GTID_EXECUTED，但 recovery channel 可能仍在后台拉取 binlog，导致后续 START GROUP_REPLICATION 时因 GTID gap 报 Member has more executed transactions than those present in the group。
- 务必在
RESET MASTER后，手动执行SET GLOBAL GTID_PURGED = 'xxx';，值来自当前集群的SELECT @@GLOBAL.GTID_EXECUTED; - 如果集群已分裂（如脑裂残留），先人工确认哪个 GTID 集合是权威的，再同步，不能盲目 copy
-
CHANGE MASTER TO ... FOR CHANNEL 'group_replication_recovery'中的用户密码必须有replication slave权限，且账号在所有节点上存在
协议版本不一致不是配置问题，是硬性隔离。一旦发现 MEMBER_VERSION 混用，唯一安全路径就是暂停业务、逐节点升级、校验参数、最后统一启组。跳过任一环节，都可能把数据不一致埋成定时炸弹。
