如何在不影响业务的情况下升级数据库？

本文目录导读：

1. 核心原则：最小化停机时间
2. 方案A：零停机 / 极小停机时间（强烈推荐）
3. 方案B：读写分离 + 灰度升级（风险中等）
4. 方案C：在线DDL + 原地升级（风险较高，不推荐）
5. ⚠️ 升级前必须做的检查清单（预防业务影响）

在不影响业务（或尽可能降低影响）的情况下升级数据库，是一项高风险的运维操作，核心思路是“灰度、回滚、兜底”，即通过架构设计和操作流程,将升级对用户的影响降到最低。

以下是一套经过验证的步骤和策略，按风险从低到高排序,建议优先选择风险最低的方案：

核心原则：最小化停机时间

永远要有回滚方案。 升级前必须确认回滚步骤可行且已测试过回滚脚本。

先读后写。 先升级只读节点（从库），再升级读写节点（主库）。

执行前做好全量备份。 确保有最近一份完整的数据备份和Binlog/归档日志。

方案A：零停机 / 极小停机时间（强烈推荐）

适用于高可用架构（如主从复制、MySQL Group Replication、集群、云数据库）。

步骤：

1. 准备阶段（业务无感）：
   • 搭建一个与生产环境完全一致的新版本库（如：从旧库同步数据至新库，或直接购买新的云实例）。
   • 使用延迟复制： 让新库与旧库保持复制关系，但让新库落后旧库几分钟,这在回滚时非常有用。
2. 切换阶段（业务无感，可能有一两秒闪断）：
   • 方案A-1：蓝绿部署（最推荐）
     1. 在负载均衡器（如HAProxy、Nginx、云LB）后端，将写流量全部指向A组（旧库），将读流量部分指向B组（新库）。
     2. 观察B组新库运行情况（监控慢查询、错误日志、CPU/IO）。
     3. 确认B组稳定后，将写流量也切换到B组。
     4. 回滚手段： 只需将流量切回A组即可,无需回滚数据库。
   • 方案A-2：主从切换（适用于MySQL、PostgreSQL）
     1. 手动将新库提升为新主库（switchover，而非failover）。
     2. 将应用连接指向新主库。
     3. 关键点： 提前在应用端或中间件（如ProxySQL、MaxScale）配置可切换的连接池,切换时应用无需重启。

难点与解决：

• 数据一致性： 切换时需确保新库与旧库数据完全一致（无丢失）,使用GTID或LSN校对。
• 应用兼容性： 新版数据库可能弃用了一些SQL语法或特性。必须在测试环境做全量回归测试。

方案B：读写分离 + 灰度升级（风险中等）

适用于无法承受任何停机,但架构允许读写分离的场景。

步骤：

1. 搭建新库： 将新版本库作为旧库的从库。
2. 灰度读流量： 在应用层配置，让1%的读请求指向新库（观察内存、CPU、慢查询），运行1-3天。
3. 灰度写流量（高风险）： 如果只读很稳定，可以逐步将部分写流量转过去。但这是最危险的一步,因为一旦出错可能导致数据不一致。
4. 最终切换： 当灰度范围扩大到100%后,将所有的读写流量切换到新库。

风险控制：

• 熔断机制： 一旦新库出现慢查询（比旧库慢2倍以上）、复制延迟超过阈值,立即将流量切回旧库。
• 只灰度读，不灰度写： 如果不能保证写一致，只灰度读流量,写流量全量留在旧库。

方案C：在线DDL + 原地升级（风险较高，不推荐）

适用于单机库或无法做主从切换的库。

步骤：

1. 备份（必须）： 全量备份 + 开启Binlog。
2. 业务低峰期： 选择凌晨2-5点执行。
3. 停服（如果必须）： 写一个通知页面（如“系统升级中”）,或者限流。
4. 执行升级脚本： mysql_upgrade、pg_upgrade --check。
5. 验证： 运行check table、analyze table等。
6. 恢复服务。

风险：

• 致命问题： 升级脚本失败可能导致数据目录损坏，只能从备份恢复,丢失几小时数据。
• 仅在完全无法切换时使用,比如公司只有一台服务器且没有冷备。

⚠️ 升级前必须做的检查清单（预防业务影响）

即使选择了零停机方案，以下检查也不可跳过：

1. 兼容性测试（必须做）：
   • 检查废弃的SQL语法（如MySQL 8.0移除了部分旧函数）。
   • 检查驱动版本（JDBC、ODBC、连接池）是否支持新数据库版本。
   • 检查ORM框架（Hibernate、MyBatis、Sequelize）的方言配置。
2. 性能测试：
   • 在新版本上运行生产环境的慢查询，对比执行计划，新版本优化器可能变化,导致原本不慢的查询变慢。
   • 使用EXPLAIN ANALYZE对比旧旧库。
3. 自动化验证：
   • 在预发布环境全量跑一遍回归测试脚本（覆盖所有增删改查）。
4. 监控与告警：
   • 升级后第1小时，重点监控：
     • 慢查询数
     • 锁等待时间
     • 复制延迟
     • 连接数
     • 死锁

最后提醒： 升级数据库不是一次操作，而是一个项目，建议先在一个不重要的业务库（如日志库、报表库）上完整演练一遍,再对核心库操作。