MySQL集群升级必须分步滚动进行，先查清架构与节点状态，验证新版本兼容性，再按从节点到主节点顺序逐个升级并验证复制与性能。
MySQL集群升级不能直接全量替换，必须按节点分步滚动升级，确保服务不中断、数据不丢失、版本兼容性可控。
确认集群架构与当前版本
先明确你用的是哪种MySQL集群方案：MySQL Group Replication（MGR）、InnoDB Cluster、MySQL NDB Cluster，还是基于Proxy（如ProxySQL/MaxScale）+ 主从复制的自建集群。不同架构升级路径差异很大。
执行以下命令查清每个节点的版本和角色：
-
登录每个MySQL实例：
SELECT VERSION(), @@hostname, @@server_id; -
MGR集群：运行
SELECT * FROM performance_schema.replication_group_members;确认成员状态和视图ID -
主从复制集群：在主库执行
SHOW MASTER STATUS;，在从库执行SHOW SLAVE STATUS\G，重点关注Seconds_Behind_Master和IO/SQL线程状态
验证新版本兼容性与变更影响
MySQL大版本升级（如5.7→8.0）存在不兼容变更，必须提前评估：
- 检查官方升级路径文档，确认是否支持跨版本直接升级（例如5.6→8.0不被支持，需经5.7中转）
- 禁用或修改已移除的功能：如
mysql_old_password插件、NO_AUTO_CREATE_USERSQL模式、CREATE TEMPORARY TABLES权限逻辑变化 - 运行
mysql_upgrade工具（8.0.16起已弃用，改由服务器自动执行），但升级前建议用mysqld --upgrade=NONE启动做兼容性预检 - 测试应用SQL在新版本下的行为，特别是JSON函数、窗口函数、字符集（utf8mb4默认）、密码认证插件（caching_sha2_password）等
制定滚动升级步骤（以MGR/主从集群为例）
核心原则：先升级从节点，再升级主节点；每次只操作一个节点，确保其他节点持续提供服务。
-
备份所有节点：使用
mysqldump或物理备份（如Percona XtraBackup），并验证可恢复性 -
停用待升级从节点的复制（主从场景）：
STOP SLAVE;，确认已追平主库日志位置 -
关闭MySQL进程，替换二进制文件，更新配置文件（注意
basedir、datadir、plugin_dir路径及新增参数如default_authentication_plugin） - 启动新版本MySQL：首次启动会自动执行字典升级（data dictionary upgrade），需确保磁盘空间充足、无权限问题
-
重新加入集群：
- MGR：执行
START GROUP_REPLICATION;，观察performance_schema.replication_group_members状态变为ONLINE - 主从：执行
CHANGE MASTER TO ...（若GTID启用则无需手动指定位点），再START SLAVE;
- MGR：执行
-
逐个重复以上过程，直到所有从节点完成升级；最后将主库切换（如MGR可触发
SET GLOBAL group_replication_bootstrap_group=ON;重建引导，或通过mysqlsh手动切换primary）并升级原主节点
升级后必做事项
升级不是结束，而是验证的开始：
- 检查错误日志（
error.log）有无严重警告或启动失败记录 - 运行
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;（MGR）或SHOW SLAVE STATUS\G（主从）确认复制正常、无延迟 - 对比升级前后性能基线（QPS、慢查询数、连接数、锁等待），关注优化器行为变化
- 更新客户端驱动（如JDBC Connector/J 8.0+ 支持MySQL 8.0新认证方式），避免连接失败
- 更新监控项（如Prometheus exporter、Zabbix模板），适配新版本暴露的指标字段
不复杂但容易忽略——升级前的充分测试和升级中的节奏控制，比技术操作本身更重要。
