笙亿网络策划

如何平滑升级 MySQL 主从集群而不中断业务同步

约 8 分钟读完 2 阅
文章导读
MySQL 主从集群平滑升级的核心是“先升级从库、再切换主库、最后升级原主库”，通过滚动升级配合 GTID 一致性校验，可实现业务无感知的版本迭代。
📋 目录
  1. A 命令速用版
  2. B 为什么会这样
  3. C 分步处理
  4. D 怎么验证是否生效
  5. E 常见坑
  6. F 常见问题
  7. G 参考来源
A A

MySQL 主从集群平滑升级的核心是“先升级从库、再切换主库、最后升级原主库”，通过滚动升级配合 GTID 一致性校验，可实现业务无感知的版本迭代。

先说结论：生产环境升级首选主从滚动升级方案，必须完成双重备份与测试环境演练，全程在业务低峰期执行并预留回滚时间。

  • 适合：已部署主从复制架构或高可用组件（如 MHA/Orchestrator）的生产环境
  • 先看：确认 binlog_format=ROW、gtid_mode=ON 及版本兼容性路径
  • 建议：升级从库验证稳定后再切换主库，避免直接原地升级主节点

命令速用版

以下命令用于检查复制状态与控制升级流程，执行前请确保有足够权限。

STOP SLAVE; -- 停止从库复制线程
START SLAVE; -- 启动从库复制线程
SHOW SLAVE STATUS\G -- 检查复制延迟与错误
SELECT * FROM performance_schema.replication_group_members; -- MGR 集群成员状态检查
SET GLOBAL sql_slave_skip_counter = 1; -- 非 GTID 模式下跳过错误事务（谨慎使用）

为什么会这样

升级过程中主从同步中断通常是因为 binlog 格式、GTID 状态或复制协议版本不兼容，导致 IO_THREAD 或 SQL_THREAD 报错停止。

例如 5.7 升级至 8.0 时，若从库未开启 enforce_gtid_consistency=ON，即使主库开启，复制也会卡在事务校验阶段；8.0.23+ 默认启用 binlog 事务压缩，老版本从库无法解压会导致 Seconds_Behind_Master 突变为 NULL。此外，认证插件变更（如 caching_sha2_password 成为默认）可能导致老客户端连接失败。

分步处理

按照“备份 - 升级从库 - 切换主库 - 升级原主库”的顺序执行，确保每一步都有验证点。

1. 升级前准备与兼容性检查
确认目标版本与当前版本之间的兼容性变更，比如弃用的参数、移除的功能或默认值变化。必须进行一次全量备份（物理备份如 XtraBackup 或逻辑备份如 mysqldump），并验证备份文件可恢复。在测试环境模拟升级流程，观察是否有报错或性能下降。

如何平滑升级 MySQL 主从集群而不中断业务同步

2. 升级从库（Slave）
停止从库的复制线程（STOP SLAVE），备份从库数据。关闭 MySQL 服务，安装新版本 MySQL 二进制文件，更新 my.cnf 配置（注意兼容参数，如移除废弃选项 innodb_locks_unsafe_for_binlog）。启动 MySQL 服务，检查错误日志。MySQL 8.0.16+ 可省略 mysql_upgrade 命令，但建议仍执行以检查系统表兼容性。重新启动复制（START SLAVE），查看复制状态，确认 Seconds_Behind_Master 为 0 且无错误。

3. 主从角色切换
确保所有从库已追上主库，停止原主库写入（或进入只读模式）。在新主库（原从库）执行 STOP SLAVE; RESET SLAVE ALL;，应用新的主库配置。将应用连接指向新主库，将原主库作为从库重新接入复制链路并升级。

4. 升级原主库
将原主库降级为从库后，按照升级从库的流程进行操作。升级完成后运行 mysql_upgrade 检查系统表兼容性。

怎么验证是否生效

验证不能只看“能连上、能查数据”，要覆盖真实业务链路与复制状态。

复制状态验证：执行 SHOW SLAVE STATUS\G，确认 Seconds_Behind_Master = 0 且 Slave_IO_Running 与 Slave_SQL_Running 均为 Yes。对于 MGR 集群，运行 SELECT * FROM performance_schema.replication_group_members;，确认所有节点 MEMBER_STATE 是 ONLINE，且只有一个节点的 MEMBER_ROLE 为 PRIMARY。

业务链路验证：用应用账号执行典型 DML（INSERT/UPDATE/SELECT/FOR UPDATE）和 DDL（ALTER TABLE ADD COLUMN）。模拟并发更新同一行，验证隔离级别表现是否符合预期。对比升级前后相同 SQL 的执行计划（EXPLAIN FORMAT=tree），警惕索引失效。

如何平滑升级 MySQL 主从集群而不中断业务同步

数据一致性验证：使用新版本 mysqldump 或 xtrabackup 备份，再恢复到临时实例，执行一致性比对（pt-table-checksum）。

常见坑

以下场景容易引发升级失败或同步中断，操作时需格外谨慎。

1. mysql_upgrade 命令变更
MySQL 8.0.16+ 已弃用 mysql_upgrade 命令，改由服务器自动执行，但建议仍手动执行以检查系统表兼容性。若忽略此步骤，可能导致权限表或系统表结构不一致。

2. binlog 压缩兼容性
8.0.23+ 默认启用 binlog_transaction_compression=ON，老版本从库无法解压，SHOW SLAVE STATUS 里 Seconds_Behind_Master 会突变为 NULL。升级前需确认从库版本支持该特性或显式关闭压缩。

3. GTID 模式切换
跳过 DDL 的临时方案（如 SET GLOBAL sql_slave_skip_counter=1）在 GTID 模式下完全失效，必须用 gtid_executed 手动注入空事务。切换主库前必须确认旧主停写、从库 GTID 集完整、新主正确设置 gtid_purged。

4. 认证插件变更
8.0 默认认证插件变为 caching_sha2_password，老客户端需升级或配置 fallback，否则应用连接会报错。

如何平滑升级 MySQL 主从集群而不中断业务同步

常见问题

MySQL 支持跨大版本直接升级吗？

不支持，必须遵循官方推荐路径逐级升级。

例如从 5.7 到 8.0，建议先升至 5.7 最新小版本，再升至 8.0，而不是直接从 5.6 跳到 8.0。跨大版本直接升级可能导致 SQL 模式变化、废弃语法报错或字符集默认值改变。

升级过程中主从同步中断了怎么办？

重点检查 binlog 格式、GTID 状态及复制协议版本是否一致。

常见错误是 ER_MASTER_FATAL_ERROR_READING_BINLOG 或 Cannot replicate because the master version is higher than slave。若是 GTID 模式，需核对 Retrieved_Gtid_Set 是否包含旧主库的完整 GTID 集，必要时手动注入空事务。

如何保证升级失败能快速回滚？

升级前必须完成全量备份并验证有效性，保留旧版本二进制文件。

若升级后出现严重兼容性问题，可停止新版本服务，恢复旧版本二进制与配置文件，利用备份数据恢复。若已切换主库，需将流量切回旧主库并修复数据一致性。

参考来源

  • 如何升级 mysql 而不影响业务_平滑升级思路
  • 如何在不停机情况下升级 mysql_在线升级方案
  • 如何在升级 MySQL 时保证业务零中断_通过 MGR 集群实现滚动升级
  • mysql 升级时如何避免服务中断
  • mysql 如何升级主从复制_mysql 主从复制升级方法
  • MySQL 升级过程中如何保持主从数据同步_在线切换主库方法
  • 如何升级主从架构_mysql 架构升级思路
  • 低停机！一文搞定 MySQL 生产环境平滑升级
  • 如何在 mysql 中进行平滑版本升级
  • 如何在 mysql 中迁移数据避免中断服务