MySQL 8.0 MGR滚动升级要求组内节点最终统一为同一GA版本，执行SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;可检查版本混用状态，若存在5.7与8.0并存则处于过渡态，需按序完成全部节点升级并确保协议兼容。
检查组内成员版本是否混用
MySQL 8.0 的 Group Replication（MGR）允许组内短暂存在不同版本的节点（如 5.7 和 8.0 共存），但这是过渡态，不是稳定态。官方明确建议：升级过程中必须确保所有成员最终统一为同一 GA 版本（例如全为 8.0.27），否则可能触发协议不兼容、状态同步失败或事务拒绝提交。
执行以下语句确认当前组成员版本分布：
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_VERSION FROM performance_schema.replication_group_members;
注意：MEMBER_VERSION 字段返回的是 MySQL Server 版本，不是 MGR 插件版本——二者在 5.7 和 8.0 中是强绑定的。若结果中出现 5.7.35 和 8.0.27 并存，说明已进入滚动升级流程；若全是 5.7.x，则尚未开始升级，需先做单节点兼容性检查。
运行 upgrade checker 前必须停掉组复制
MySQL Shell 的 util.checkForServerUpgrade() 工具无法在 group_replication 插件启用状态下运行，会直接报错 ER_GROUP_REPLICATION_PLUGIN_IS_ON。这是最容易卡住的第一步。
对每个待升级的从节点（主节点最后升），按顺序执行：
STOP GROUP_REPLICATION;- 确认插件已卸载：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'group_replication';—— 返回空或DISABLED - 再运行检查命令，例如：
mysqlsh -- util check-for-server-upgrade --user=root --socket=/tmp/mysql.sock --target-version=8.0.27 --output-format=JSON
输出中的 ERROR 级别问题必须修复（如 utf8mb3 字符集使用、废弃的 query_cache 配置），WARNING 可评估后决定是否处理。
升级单个节点时的配置与启动差异
从 5.7 升级到 8.0 后首次启动，不能直接用原 my.cnf 启动。8.0 引入了大量参数变更，比如：
-
default_authentication_plugin默认值从mysql_native_password变为caching_sha2_password，应用连接器不支持会导致认证失败 -
sql_mode默认新增STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY，旧 SQL 可能报错 -
log_error_verbosity替代了旧版的log_warnings，漏配会导致错误日志不全 -
performance_schema表结构自动升级，但需确保磁盘空间足够（升级过程会重建系统表）
建议做法：保留原配置文件副本，新建 my-80.cnf，仅保留 8.0 兼容的参数，并显式设置 default_authentication_plugin=mysql_native_password（升级完成后再逐步切回 caching_sha2_password）。
重连 MGR 时的协议版本和引导风险
节点以 8.0 启动并完成数据字典升级后，重新加入组前必须确认两件事：
- 组内其他节点是否已全部升级？如果还有 5.7 节点在线，8.0 节点尝试
START GROUP_REPLICATION会因通讯协议不匹配而卡在RECOVERING状态，日志中出现Member has a different version than the majority - 首次加入必须用
group_replication_start_on_boot=OFF，避免 mysqld 启动时自动拉起组复制导致状态混乱 - 启动后手动执行：
SET GLOBAL group_replication_bootstrap_group=ON;（仅限第一个 8.0 节点），之后立即设为OFF，再START GROUP_REPLICATION
真正麻烦的不是升级动作本身，而是“以为升级完了就结束了”——MGR 集群的可用性取决于最后一个节点完成同步且状态变为 ONLINE，而这个过程可能因网络抖动、GTID gap 或 binlog 格式不一致被静默阻塞数分钟。务必盯住 performance_schema.replication_group_members 和错误日志里的 GROUP_REPLICATION 关键字行。
