先确认版本兼容性、应用依赖及备份完整性，再按架构选择升级路径。对Group Replication或InnoDB Cluster采用滚动升级，先升从节点最后升主节点；MHA/Orchestrator架构先升备库再切换主库；PXC需停集群全量升级。替换二进制后启动实例并运行mysql_upgrade，验证节点状态与复制正常。升级后检查集群可用性、性能指标及监控告警，更新文档，特别注意sql_mode和caching_sha2_password认证插件带来的连接风险。
在 MySQL 中升级高可用集群是一项需要谨慎操作的任务，因为涉及多个节点、数据一致性以及服务连续性。常见的 MySQL 高可用架构包括基于 MySQL Group Replication、InnoDB Cluster（通过 MySQL Shell 管理）、Percona XtraDB Cluster (PXC) 或使用中间件如 ProxySQL + MHA/Orchestrator 的主从复制方案。以下是通用的升级流程和关键注意事项。
评估当前环境与目标版本兼容性
在开始升级前，必须确认以下几点：
- 当前 MySQL 版本与目标版本之间的兼容性：查看官方文档中关于版本间的变更日志，特别是系统表结构、参数废弃、字符集默认值等变化。
- 存储引擎支持情况：确保使用的 InnoDB、MyISAM 等引擎在新版本中仍被支持且行为一致。
- 应用兼容性：检查应用程序是否依赖某些已被弃用的语法或功能。
- 备份现有集群状态：对所有节点进行完整物理或逻辑备份（建议使用 Percona XtraBackup 或 mysqldump），并验证可恢复性。
选择合适的升级路径
根据部署方式不同，升级策略也有所区别：
场景一：基于 MySQL Group Replication / InnoDB Cluster
- 支持滚动升级（Rolling Upgrade），即逐个节点停机升级，不影响整体集群可用性。
- 使用 MySQL Shell 可以自动检测集群状态并引导升级过程：
dba.upgradeToInnoDBCluster()或cluster.setupRouter()等命令配合版本迁移。 - 先升级种子成员以外的节点，最后升级担任 primary 角色的节点（对于单主模式）。
场景二：主从复制 + MHA/Orchestrator 架构
- 先升级备库（Slave/Replica），再切换主库（Master），实现无缝过渡。
- 升级过程中暂停复制线程，更新软件后重启实例，并重新启用复制。
- MHA 需要手动控制 failover 流程；Orchestrator 支持更灵活的在线切换。
场景三：Percona XtraDB Cluster (PXC)
- PXC 不支持跨大版本的在线升级（如 5.7 → 8.0 必须停集群）。
- 推荐采用“关闭整个集群 → 升级所有节点 → 按顺序启动”的方式。
- 注意 wsrep_provider 版本与 MySQL 主版本匹配。
执行升级操作的关键步骤
无论哪种架构，基本流程如下：
- 停止 MySQL 服务：在待升级节点上安全关闭 mysqld 进程。
- 替换二进制文件或 RPM/DEB 包：
-
启动 MySQL 并运行 mysql_upgrade：
- MySQL 8.0 起
mysql_upgrade已整合进 mysqld 启动流程，但仍需留意输出日志。 - 该步骤会检查系统表、修复权限、更新字典数据等。
- MySQL 8.0 起
-
验证节点加入集群状态：
- 查看 error log 是否有异常。
- 执行
SHOW DATABASES;、SELECT * FROM performance_schema.replication_group_members;确认正常加入。
升级后的验证与监控
完成所有节点升级后，务必进行以下检查：
- 确认集群各节点处于 ONLINE 状态，无延迟或报错。
- 测试读写流量是否正常，尤其是事务提交、DDL 执行性能。
- 检查慢查询日志、连接数、锁等待等指标是否有异常波动。
- 更新监控系统（如 Prometheus + Grafana、Zabbix）中关于 MySQL 版本的告警规则。
- 更新文档，记录升级时间、版本信息、回滚方案等。
基本上就这些。关键是做好备份、按顺序操作、密切观察日志。虽然流程看似复杂，但只要规划得当，MySQL 高可用集群的升级是可以平稳完成的。不复杂但容易忽略的是参数兼容性和认证插件的变化，比如 native password 到 caching_sha2_password 的切换可能导致客户端连接失败，记得提前处理。
