先确认版本兼容性、应用依赖及备份完整性，再按架构选择升级路径。对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 架构

聚好用AI

可免费ai绘图、AI音乐、AI视频创作，聚集全球顶级AI，一站式创意平台

115

查看详情

• 先升级备库（Slave/Replica），再切换主库（Master），实现无缝过渡。
• 升级过程中暂停复制线程，更新软件后重启实例，并重新启用复制。
• MHA 需要手动控制 failover 流程；Orchestrator 支持更灵活的在线切换。

场景三：Percona XtraDB Cluster (PXC)

• PXC 不支持跨大版本的在线升级（如 5.7 → 8.0 必须停集群）。
• 推荐采用“关闭整个集群 → 升级所有节点 → 按顺序启动”的方式。
• 注意 wsrep_provider 版本与 MySQL 主版本匹配。

执行升级操作的关键步骤

无论哪种架构，基本流程如下：

• 停止 MySQL 服务：在待升级节点上安全关闭 mysqld 进程。
• 替换二进制文件或 RPM/DEB 包：
  • 使用 yum/dnf/apt 安装新版包，或手动替换 mysql-server 二进制。
  • 确保配置文件（my.cnf）中的参数与新版本兼容（例如 sql_mode、default_authentication_plugin）。
• 启动 MySQL 并运行 mysql_upgrade：
  • MySQL 8.0 起 mysql_upgrade 已整合进 mysqld 启动流程，但仍需留意输出日志。
  • 该步骤会检查系统表、修复权限、更新字典数据等。
• 验证节点加入集群状态：
  • 查看 Error log 是否有异常。
  • 执行 SHOW DATABASES;、select * FROM performance_schema.replication_group_members; 确认正常加入。

升级后的验证与监控

完成所有节点升级后，务必进行以下检查：

• 确认集群各节点处于 ONLINE 状态，无延迟或报错。
• 测试读写流量是否正常，尤其是事务提交、DDL 执行性能。
• 检查慢查询日志、连接数、锁等待等指标是否有异常波动。
• 更新监控系统（如 prometheus + grafana、zabbix）中关于 MySQL 版本的告警规则。
• 更新文档，记录升级时间、版本信息、回滚方案等。

基本上就这些。关键是做好备份、按顺序操作、密切观察日志。虽然流程看似复杂，但只要规划得当，MySQL 高可用集群的升级是可以平稳完成的。不复杂但容易忽略的是参数兼容性和认证插件的变化，比如 native password 到 caching_sha2_password 的切换可能导致客户端连接失败，记得提前处理。