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可触发
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模板），适配新版本暴露的指标字段
不复杂但容易忽略——升级前的充分测试和升级中的节奏控制，比技术操作本身更重要。
