MGR单主模式安全滚动升级需三重校验：节点状态全ONLINE且仅一PRIMARY、group_replication_primary_member UUID匹配、group_name/binlog_format/GTID三值全集群一致且binlog_format=ROW、gtid_mode=ON；升级前必须STOP GROUP_REPLICATION，禁用强杀；RECOVERING卡顿主因donor事务视图或binlog断档，需查LAST_ERROR并核对binlog范围；大版本升级须注意认证插件、sql_mode、collation变更及配置兼容性。
不能保证零中断，但可以做到业务无感——前提是严格按节点角色、版本兼容性、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 或 systemctl stop 容易残留 socket 或未释放的 group communication 线程。
- 正确操作：登录待升级节点，执行
STOP GROUP_REPLICATION;，再等SELECT MEMBER_STATE FROM performance_schema.replication_group_members WHERE MEMBER_HOST = '本机IP';返回OFFLINE - 错误操作：用
mysqladmin shutdown或kill -9强杀进程，会导致下次启动时报Group replication initialization failed: The member is not in the group - 验证是否干净退出：
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 connecting using CHANGE MASTER TO，说明 MGR 自动选的 donor 不合适，需手动指定——在新节点执行CHANGE REPLICATION SOURCE TO SOURCE_HOST='donor_ip', SOURCE_PORT=3306;（仅限调试，生产慎用） - 若报错号
1236：Could not find first log file name in binary log index file，说明 donor 的 binlog 已被 purge，升级前没设binlog_expire_logs_seconds = 604800（7天） - 通用排查：在 donor 节点执行
SHOW BINARY LOGS;，比对新节点SELECT * FROM performance_schema.replication_applier_status_by_coordinator\G中的LAST_PROCESSED_TRANSACTION是否还在 donor 的 binlog 范围内
大版本升级（如 5.7 → 8.0）最易忽略的兼容性断点
不是数据字典升级失败，而是启动参数和连接行为变更导致应用连不上或写入失败：
-
default_authentication_plugin默认变为caching_sha2_password，老应用连接串没加?allowPublicKeyRetrieval=true&useSSL=false就会报Public Key Retrieval is not allowed -
sql_mode默认新增STRICT_TRANS_TABLES，有隐式类型转换的 INSERT 会直接报错，不是警告 -
utf8mb4_0900_ai_ci成为默认 collation，若唯一索引依赖utf8mb4_unicode_ci的排序逻辑，升级后可能因比较结果变化导致重复键冲突 - 配置里还留着
sql_mode=NO_AUTO_CREATE_USER？8.0 启动直接拒绝，必须删掉
跨大版本混跑不被官方支持，哪怕只差一个节点没升级完，整个组就处于高风险状态——选主算法会降级适配，但事务一致性边界变模糊，别心存侥幸。
