必须先停用group_replication插件，否则util.checkForServerUpgrade()会报ER_GROUP_REPLICATION_PLUGIN_IS_ON错误；正确步骤为：STOP GROUP_REPLICATION，确认PLUGIN_STATUS为DISABLED或空，再执行检查命令。
升级前必须停掉 group_replication 插件
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
MGR 组内版本混用是过渡态，不是稳定态
MySQL 8.0 允许组内短暂存在 5.7 和 8.0 节点共存（MEMBER_VERSION 显示不同），但这只是滚动升级过程中的中间状态，官方明确要求最终所有节点必须统一为同一 GA 版本（如全为 8.0.27）。
检查方式很简单：
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_VERSION FROM performance_schema.replication_group_members;- 若结果中同时出现
5.7.35和8.0.27，说明你正处于过渡态；若全是5.7.x，则尚未开始升级
混用时间过长或未完成全部节点升级，可能触发协议不兼容、状态同步失败或事务被拒绝提交。
升级从节点时卡在 RECOVERING 的真实原因
这不是网络延迟或磁盘 IO 问题，而是 donor 节点的事务视图不一致或 binlog 断档导致恢复失败。
快速定位方法：
- 查
performance_schema.replication_connection_status表的LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE - 典型错误如
3024: The slave is connec...（截断提示），本质是 donor 缺失所需 binlog event 或 GTID 不连续 - 必须核对 donor 的
SHOW MASTER LOGS范围与该节点Retrieved_Gtid_Set是否覆盖
首次启动 8.0 不能直接复用原 my.cnf
MySQL 5.7 的配置文件在 8.0 上大概率启动失败，尤其涉及认证、SQL 模式和日志机制等默认值变更。
关键兼容性补丁必须手动加：
-
default_authentication_plugin=mysql_native_password（否则老客户端连不上） - 移除或注释掉已废弃项：
query_cache_type、explicit_defaults_for_timestamp（8.0 默认启用） - 确认
binlog_format=ROW且gtid_mode=ON—— 这两项必须全集群一致，否则 MGR 启动即拒
最稳妥做法：用 mysqld --initialize-insecure --basedir=/path/to/8.0 初始化干净实例，再逐条迁移必要配置，而不是直接覆盖启动。
