<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>
可以做到业务无感，但绝不是“零中断”——前提是严格按节点角色、版本兼容性、GTID一致性三重校验后执行滚动升级。跳过任一环节，大概率触发 RECOVERING 卡死或复制断裂。
怎么确认当前是 MGR 单主模式且可安全滚动升级
别信配置文件里写的 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应无监听
升级后节点卡在 RECOVERING 怎么快速定位
这不是网络问题，是 donor 节点事务视图或 binlog 断档导致的恢复失败。
- 重点看
performance_schema.replication_connection_status的LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE - 若报错号
3024：The slave is connec...（截断），说明 donor 的 binlog 已被 purge，需检查SELECT @@expire_logs_days, @@binlog_expire_logs_seconds;及 donor 上SHOW BINARY LOGS;的最小文件序号 - 若报错含
view change或certification failure，大概率是升级前后transaction_write_set_extraction值不一致（如从XXHASH64改成XXHASH64以外的值） - 切勿在
RECOVERING状态下强行START GROUP_REPLICATION；应先RESET SLAVE ALL;，再核对 donor binlog 范围与本地gtid_executed是否可衔接
最容易被忽略的是：大版本升级（如 5.7 → 8.0）时，default_authentication_plugin 默认值变更、sql_mode 新增严格项、collation_server 兼容性变化，这些不会立刻报错，但会导致应用连接失败或隐式类型转换异常——务必在升级前用 mysqld --no-defaults --verbose --help | grep "default_authentication_plugin" 对比新旧版本默认值。
