为什么单独走专项
数据库与中间件的补丁不能按“顺手打一次”处理：小版本升级牵动主从复制兼容、驱动与协议匹配、SQL 行为变更；大版本升级本质是一次数据迁移。这类变更通常单独排专项窗口，按“先升从库、切换验证、再升主库”的顺序推进，并预先准备好数据一致性校验与回滚方案。风险点集中在上层应用的兼容性，而不是补丁本身。
基本信息
| 适用平台 | MySQL/MariaDB、PostgreSQL、Oracle、SQL Server、Redis、MQ 等 |
|---|---|
| 风险等级 | 高 |
| 基线 | 有专项方案、有演练、有回滚路径 |
| 窗口 | 单独排期，避开业务高峰与月度批量补丁 |
| 参与方 | DBA、应用负责人、运维、值班 |
典型使用场景
- 修复数据库自身高危漏洞（提权、越权、远程执行）
- 小版本补丁更新，例如 8.0.x 内的累积修复
- 大版本升级，例如 MySQL 5.7 到 8.0，需要数据校验与迁移方案
- 中间件补丁（Redis、Nginx、消息队列）与驱动同步升级
- 主从架构调整期，需要在切换窗口内顺带完成升级
专项检查点
专项检查点
echo '1) 拓扑与角色：主库 / 从库 / 只读副本 / 代理层'
echo '2) 升级路径：小版本直升，还是大版本迁移'
echo '3) 应用兼容：驱动版本、协议、SQL 行为变更、默认参数变化'
echo '4) 回滚：小版本通常可回退；大版本多数不可逆，需保留旧实例'
echo '5) 演练：从库先升 → 切换验证 → 主库升级 → 反向切回演练'
mysql --version; mysqladmin status | head -3 # 升级前后对比版本与运行态
SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_buffer_pool_size';变更类型对照
| 变更类型 | 典型动作 | 回滚难度 |
|---|---|---|
| 小版本补丁 | 停实例、装包、启动、验证 | 低，可回退旧包 |
| 大版本升级 | 数据校验、迁移、应用改造 | 高，通常需保留旧实例 |
| 中间件补丁 | 滚动重启、连接池验证 | 中，注意连接中断 |
| 驱动升级 | 应用侧灰度发布 | 中，需兼容旧服务端 |
大版本升级本质是迁移项目：必须做数据一致性校验（行数、校验和、抽样比对）与回滚方案，不能当作“装个补丁”推进。
补丁窗口内建议暂停备份作业与批处理任务，避免升级验证阶段被后台任务干扰，导致结论不可信。