<p>必须先查实时状态：执行SELECT * FROM performance_schema.replication_group_members;确认所有节点MEMBER_STATE为ONLINE且仅一个MEMBER_ROLE为PRIMARY；再用SHOW STATUS LIKE 'group_replication_primary_member';核对UUID匹配；最后检查@@group_replication_group_name、@@binlog_format(须为ROW)、@@gtid_mode(须为ON)全集群一致。</p>
MySQL组复制（Group Replication）集群滚动升级不是“换完二进制就重启”，而是必须严格按节点状态、GTID一致性、通信协议版本三重校验后逐节点操作；跳过任一环节，节点大概率卡在 RECOVERING 状态无法恢复。
怎么确认当前是单主模式且可安全滚动升级
别信配置文件里写的 group_replication_single_primary_mode=ON，得查实时状态：
- 运行
SELECT * FROM performance_schema.replication_group_members;，确认所有节点MEMBER_STATE是ONLINE，且只有一个节点的MEMBER_ROLE为PRIMARY - 执行
SHOW STATUS LIKE 'group_replication_primary_member';，输出的 UUID 必须和上一步中MEMBER_ID匹配 - 检查
SELECT @@group_replication_group_name, @@binlog_format, @@gtid_mode;—— 三个值必须全集群一致，且binlog_format必须是ROW，gtid_mode必须是ON；若不是，先改配置、重启节点，再继续
为什么升级前必须先执行 STOP GROUP_REPLICATION
这不是为了停服务，而是避免新节点启动后自动尝试加入组时，因版本不匹配被拒绝或卡在 RECOVERING。MGR 在 8.0.17+ 后会强制只读（super_read_only=ON），但旧版不会，直接 kill -9 或 mysqladmin shutdown 容易残留 socket 或未释放的 group communication 线程。
- 正确操作：登录待升级节点，执行
STOP GROUP_REPLICATION;，再等SELECT MEMBER_STATE FROM performance_schema.replication_group_members WHERE MEMBER_HOST = '本机IP';返回OFFLINE - 验证是否干净退出：
ps aux | grep mysqld应无残留进程，netstat -tlnp | grep :3306应无监听 - 错误操作：用
mysqladmin shutdown或kill -9强杀进程，会导致下次启动时报Group replication initialization failed: The member is not in the group
升级后节点卡在 RECOVERING 怎么快速定位
这不是网络问题，90% 是 GTID 或事务视图不匹配。新节点启动后会尝试从 donor 拉取缺失事务，但 donor 可能已 purge 掉旧 binlog。
- 查
SELECT * FROM performance_schema.replication_connection_status\G，重点看LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE - 若报错号
3024（The slave is connecting using CHANGE MASTER TO），说明 donor 选错了；若是1236（Could not find first log file name in binary log index file），说明 donor 的 binlog 被清空 - 最稳方案：升级前在所有节点执行
SET GLOBAL binlog_expire_logs_seconds = 604800;（7天），避免自动 purge - 注意：MySQL 官方不支持 Group Replication 跨大版本混跑，5.7 和 8.0 并存只是过渡态，必须最终统一为同一 GA 版本（如全为 8.0.27）
Operator 管理的 MGR 集群升级要额外防什么
Kubernetes 中用 Operator 管理 MySQL 集群时，滚动升级失败往往不是 MySQL 层面的问题，而是 Operator 自身行为没对齐 MGR 要求：
- 确认
StatefulSet的updateStrategy.rollingUpdate.partition设为合理值（如设为2表示只升级序号 ≥2 的 Pod） - 检查 CR 中
spec.podManagementPolicy是否为OrderedReady（必须，否则并行启动会破坏主从同步顺序） - 确保每个 Pod 有独立
PVC——不能共用同一个volumeClaimTemplates名称但未加{{.Index}}模板变量 - Operator 升级后主从复制中断，
SHOW SLAVE STATUS\G显示Seconds_Behind_Master: NULL，常见原因是 Operator 仍硬编码主 Pod 为mysql-0，而滚动升级时该 Pod 被重建；应启用spec.replication.gtid: true并升级 Operator 到 v0.17.0+ 支持自动 failover 的版本
最容易被忽略的是：Operator 判断 Pod “就绪” 不仅看 Phase=Running，还依赖 readiness probe 是否通过；若 MySQL 启动后还没完成组内同步就返回就绪，Operator 就会提前触发下一个 Pod 升级，引发连锁失败。
