如何进行MySQL 5.7升级到8.0的MGR集群组复制成员兼容性检查以确保顺利迁移？

本文共计934个文字，预计阅读时间需要4分钟。

MySQL 8.0 的 Group Replication (MGR) 允许组内不同版本的节点共存，但这是过渡状态，不是稳定状态。官方建议：

执行以下语句确认当前组成员版本分布：

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 关键字行。