AWS RDS MySQL 8.0 升级到 8.4 完整操作指南
作者: 指剑
日期: 2026 年 7 月
适用场景 : 本文适用于需要将 Amazon RDS for MySQL 从 8.0 升级到 8.4 的运维、DBA 及开发人员。全部操作均可通过 AWS 控制台完成,同时提供 AWS CLI 命令作为参考。

目录
- 前言
- 版本生命周期与升级必要性
- 升级前准备:兼容性检查清单
- [MySQL 8.4 主要变化与注意事项](#MySQL 8.4 主要变化与注意事项)
- 升级方案对比与选择
- 方案一:控制台就地升级
- 方案二:蓝绿部署升级(推荐)
- 升级后验证
- 回滚方案
- 案例测试:模拟真实业务升级
- 总结与最佳实践
- 参考资料
1. 前言
Amazon RDS for MySQL 是亚马逊云科技提供的完全托管 MySQL 数据库服务,自动处理硬件配置、数据库设置、补丁更新和备份等运维任务。随着 MySQL 8.0 宣布标准支持周期即将结束,以及 MySQL 8.4 系列功能的不断成熟,越来越多的企业开始考虑将生产环境迁移至 MySQL 8.4。
核心驱动力:
| 因素 | 说明 |
|---|---|
| 🔴 标准支持终止 | MySQL 8.0 标准支持将于 2026 年 7 月 31 日 结束 |
| 🟢 性能提升 | 8.4 在中低并发读场景有 20%+ 提升 |
| 🔒 安全增强 | 默认更强的认证方式、弱密码套件移除 |
| ⚡ 新功能 | SQL 增强、EXPLAIN 改进、GTID 标签等 |

本文将从实际操作角度,详细介绍如何通过 AWS 控制台完成从 RDS MySQL 8.0 到 8.4 的升级,包含完整的兼容性检查、操作步骤、注意事项以及一个完整的案例测试,帮助您平稳完成数据库升级。
2. 版本生命周期与升级必要性
2.1 关键时间节点
| 事件 | 日期 |
|---|---|
| MySQL 8.0 标准支持终止 | 2026 年 7 月 31 日 |
| RDS 扩展支持开始 | 2026 年 7 月 31 日后自动启用 |
| 建议完成升级时间 | 2026 年 7 月 31 日之前 |
2.2 停止支持后的影响
- 如果在创建或还原数据库实例时没有禁用 RDS 扩展支持,Amazon RDS 会自动将它们注册到 RDS 扩展支持,并收取相应费用
- 如果尚未运行在标准支持终止日期之前发布的最后一个次要版本,Amazon RDS 会自动将实例升级到该次要版本
- 扩展支持费用会持续产生,建议尽早规划升级
注意 :更多版本生命周期信息,请参阅 Amazon RDS 上支持的 MySQL 主要版本。
3. 升级前准备:兼容性检查清单
⚠️ 重要 :升级前请务必在测试环境完成所有兼容性检查,切勿直接在生产环境操作。
3.1 检查当前实例状态
控制台操作:
RDS 控制台 → 数据库 → 选择实例 → 查看「配置」选项卡中的引擎版本信息

RDS 控制台 - 实例详情页显示 MySQL 8.0 版本
CLI 命令参考:
bash
aws rds describe-db-instances \
--db-instance-identifier <your-db-instance> \
--query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion,MultiAZ:MultiAZ}' \
--region <your-region>

3.2 确认可升级的目标版本
控制台操作:
RDS 控制台 → 数据库 → 选择实例 → 操作 → 「修改」 → 数据库引擎版本下拉列表查看可选版本

修改实例页面 - 数据库引擎版本下拉列表
CLI 命令参考:
bash
aws rds describe-db-engine-versions \
--engine mysql \
--engine-version 8.0 \
--query 'DBEngineVersions[0].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion' \
--region <your-region>

3.3 SQL 语法兼容性检查
这是升级前最重要的步骤之一。8.0 → 8.4 包含一些不兼容的变更,建议通过以下方式检查:
方式一:使用 MySQL Shell 的升级检查工具
bash
# 安装 MySQL Shell(本地或跳板机)
# 运行升级检查
mysqlsh --- util check-for-server-upgrade ---host=<your-rds-endpoint> ---user=admin ---password
方式二:手动检查常见不兼容项
| 检查项 | 说明 | 操作 |
|---|---|---|
| 废弃函数和语法 | 检查是否使用了 8.4 中已移除的函数 | SELECT * FROM information_schema.ROUTINES 检查 |
| GROUP BY 隐式排序 | MySQL 8.0 已移除,检查应用代码 | 替换为显式 ORDER BY |
| 保留关键字 | 8.4 新增的保留字 | 检查表和列名是否冲突 |
| 时区变更 | 确认时区配置兼容性 | 检查 time_zone 参数设置 |
| SQL 模式 | 检查 sql_mode 配置 |
SELECT @@GLOBAL.sql_mode; |
MySQL 8.4 中需要特别关注的 SQL 变化:
新增集合操作:
sql
-- 8.4 支持 EXCEPT 和 INTERSECT,使用哈希表优化
SELECT * FROM table_a
EXCEPT
SELECT * FROM table_b;
SELECT * FROM table_a
INTERSECT
SELECT * FROM table_b;
EXPLAIN 改进:
sql
-- 8.4 支持 FORMAT=JSON INTO 选项
EXPLAIN FORMAT=JSON INTO @my_explain SELECT * FROM my_table;
-- 支持 FOR SCHEMA 选项
EXPLAIN FOR SCHEMA my_schema SELECT * FROM users;
标量相关子查询优化:
sql
-- 8.4 扩展了将标量相关子查询转换为派生表的优化支持
SELECT * FROM orders o
WHERE o.total > (SELECT AVG(total) FROM orders WHERE customer_id = o.customer_id);
3.4 参数组准备
建议:不要直接修改默认参数组,而是创建自定义参数组。
控制台操作:
RDS 控制台 → 参数组 → 创建参数组 → 选择 mysql8.4 族 → 创建完成后与目标实例关联

创建参数组页面 - 选择 mysql8.4 参数组族
关键参数检查清单:
| 参数 | 8.0 默认值 | 8.4 默认值 | 是否需要调整 |
|---|---|---|---|
innodb_io_capacity |
200 | 10000 | ⚠️ 需根据磁盘 IOPS 调整 |
innodb_io_capacity_max |
2000 | 20000 | ⚠️ 同上 |
innodb_log_buffer_size |
16MB | 64MB | 无需调整(变大更好) |
authentication_policy |
自定义 | :caching_sha2_password | ⚠️ 关键变更,见下文 |
adaptive_hash_index |
ON | OFF | ⚠️ 注意性能影响 |
🔑 最重要的参数调整 :
innodb_io_capacity从 200 变为 10000,如果磁盘 IOPS(如 gp3 默认 3000 IOPS)低于配置值,会导致高并发下写请求延迟显著增高。请务必根据自身磁盘配置优化这两个参数!
3.5 确保备份已启用
蓝绿部署要求源实例启用自动备份(BackupRetentionPeriod > 0)。
控制台操作:
RDS 控制台 → 数据库 → 选择实例 → 修改 → 备份 → 设置备份保留期 ≥ 7 天

修改实例 - 备份设置页
CLI 命令参考:
bash
aws rds modify-db-instance \
--db-instance-identifier <your-db-instance> \
--backup-retention-period 7 \
--apply-immediately
3.6 创建升级前快照(最后的安全网)
控制台操作:
RDS 控制台 → 数据库 → 选择实例 → 操作 → 创建快照

创建数据库快照页面
CLI 命令参考:
bash
aws rds create-db-snapshot \
--db-instance-identifier <your-db-instance> \
--db-snapshot-identifier pre-upgrade-snapshot-202607 \
--region <your-region>
4. MySQL 8.4 主要变化与注意事项
4.1 认证插件变化(⚠️ 最高风险项)
这是升级到 8.4 后最容易引发故障的变更,请务必关注。
| 变化 | 说明 |
|---|---|
mysql_native_password 默认禁用 |
从 MySQL 4.0 开始使用的认证方式默认不再启用 |
authentication_policy 新默认值 |
":caching_sha2_password",新用户默认使用更安全的 caching_sha2_password |
default_authentication_plugin 已移除 |
使用 authentication_policy 替代 |
可能引发的问题:
plain
ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded
受影响的客户端版本:
| 客户端库 | 受影响版本 | 解决方案 |
|---|---|---|
| MySQL Connector/J | < 8.0.9 | 升级到 ≥ 8.0.9 |
| PHP mysqli/PDO | < 7.4 | 升级 PHP 版本 |
| Python PyMySQL | < 0.9.0 | 升级 PyMySQL |
| js mysql2 | < 1.6.0 | 升级 mysql2 |
| 旧版 MySQL 命令行工具 | 所有旧版 | 升级客户端工具 |
三种解决方案:
- 方案 1(推荐) :升级客户端库以支持
caching_sha2_password
sql
-- 临时方案:修改现有用户认证方式
ALTER USER 'your_username'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;
- 方案 2(短期过渡) :修改 RDS 参数组全局配置,使用旧的认证方式
- 进入 RDS → 参数组
- 修改
authentication_policy参数为:*:mysql_native_password - 应用到实例并重启
- 方案 3(长期方案):升级应用程序使用的所有数据库客户端库
4.2 安全改进
| 改进项 | 说明 |
|---|---|
| 弱密码套件移除 | 不再支持不符合安全标准的加密套件 |
| 证书验证增强 | 新增 tls-certificates-enforced-validation 系统变量 |
| LDAP 认证超时 | 新增连接和响应超时配置 |
4.3 新增权限
sql
-- FLUSH_PRIVILEGES 权限:专门用于 FLUSH PRIVILEGES 语句
-- OPTIMIZE_LOCAL_TABLE 权限:用于本地表优化操作
-- TRANSACTION_GTID_TAG 权限:用于 GTID 标签功能
4.4 移除的参数和变量
⚠️ 如果您的应用或脚本引用了以下参数,请务必提前修改:
| 旧参数 | 替代方案 |
|---|---|
binlog_transaction_dependency_tracking |
已移除,无需替代 |
default_authentication_plugin |
使用 authentication_policy 替代 |
expire_logs_days |
使用二进制日志配置方式替代 |
MASTER 关键字(Binlog 复制) |
使用 SOURCE 关键字替代 |
示例:
sql
-- 旧语法(8.0)
CHANGE MASTER TO MASTER_HOST='...';
SHOW SLAVE STATUS;
-- 新语法(8.4)
CHANGE REPLICATION SOURCE TO SOURCE_HOST='...';
SHOW REPLICA STATUS;
4.5 性能变化总结
根据 sysbench 1.0.20 跨 AZ 对 r7g.large 多可用区实例的基准性能测试结果(250 张表 × 25,000 行/表):
| 场景 | 性能变化 | 说明 |
|---|---|---|
| 低并发读 | +20% 以上 | 明显提升 |
| 高并发读 | 基本持平 | 无明显变化 |
| 低并发写 | 持平 | 无明显变化 |
| 高并发写(默认参数) | 下降 7%-22% | ⚠️ 需优化 innodb_io_capacity 参数 |
| 高并发写(优化后) | 持平 | 调整参数后回归 |
4.6 直方图自动更新
sql
-- 8.4 支持在 ANALYZE TABLE 时自动更新直方图
ANALYZE TABLE my_table UPDATE HISTOGRAM ON column_a, column_b;
5. 升级方案对比与选择
5.1 方案概览
| 维度 | 就地升级 | 蓝绿部署升级 |
|---|---|---|
| 操作复杂度 | ⭐ 低 | ⭐⭐⭐ 中 |
| 停机时间 | 数分钟到数十分钟 | ~30 秒断连 |
| 业务影响 | 较大 | 极小 |
| 快速回滚能力 | ❌ 需从快照恢复 | ✅ 可切回旧实例 |
| 测试机会 | ❌ 升级前无法测试 | ✅ 可在绿环境充分测试 |
| 适用场景 | 开发/测试环境 | 生产环境(推荐) |
| 成本 | 无额外成本 | 临时增加绿环境成本 |
5.2 选型建议
- 开发/测试环境 → 就地升级(简单快速)
- 生产环境 → 蓝绿部署升级(推荐)
- 追求零停机 → 蓝绿部署 + 应用双写方案(需额外开发)
6. 方案一:控制台就地升级
适用于开发/测试环境,或业务低峰期的非关键实例。
6.1 操作步骤
Step 1:进入实例修改页面
RDS 控制台 → 数据库 → 选择要升级的实例 → 点击「修改」

RDS 控制台 - 实例列表页,选中要升级的实例
Step 2:修改数据库引擎版本
在「数据库引擎选项」区域:
- 数据库引擎版本:选择 MySQL 8.4.x
- DB 实例类:建议同时考虑升级到 Graviton3/4 实例以获得更高性价比

截图:修改实例 - 数据库引擎版本下拉选择 8.4
Step 3:关联新参数组
- DB 参数组:选择预先创建好的 MySQL 8.4 参数组
- 如果之前是默认参数组,需先创建自定义参数组

修改实例 - 参数组选择
Step 4:应用修改
在「计划修改」区域:
- 选择 「立即应用」(或选择维护窗口)
- ⚠️ 立即应用会导致数据库重启,产生几秒钟的不可用时间

修改实例 - 选择立即应用
Step 5:监控升级进度
控制台查看:
RDS 控制台 → 数据库 → 选择实例 → 状态栏会显示「升级中」

实例状态显示为「升级中」



6.2 就地升级的监控脚本(可选)
如果希望在升级过程中实时观察数据库可用性,可以在终端运行以下脚本:
bash
# 读请求健康检查(每秒检查一次)
while true; do
mysql -h <your-rds-endpoint> -u admin -p"<password>" -e "SELECT NOW(), @@hostname, @@VERSION;"
sleep 1
done
# 写请求健康检查(每秒写入一条)
while true; do
mysql -h <your-rds-endpoint> -u admin -p"<password>" <database> \
-e "INSERT INTO health_check(test_time) VALUES(NOW());"
sleep 1
done
6.3 优缺点分析
优点:
- 操作简单,一个页面即可完成
- 无额外费用
缺点:
- 升级过程中数据库不可用(数分钟至数十分钟)
- 无法在升级前验证兼容性
- 回滚困难,需从快照恢复
7. 方案二:蓝绿部署升级(推荐)
✅ 生产环境首选。创建一套完整的「绿」环境,升级完成后通过 DNS 切换将流量切到新版本,业务影响极小。
7.1 整体流程
plain
┌─────────────────────────────────────────────────────────────────────────────┐
│ 蓝绿部署升级完整流程 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 阶段1 阶段2 阶段3 阶段4 │
│ 创建蓝环境 自动升级 执行切换 验证与清理 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │蓝环境 │ │绿环境 │ │绿环境 │ │绿环境 │ │
│ │MySQL8.0 │──复制─▶│MySQL8.0 │──升级─▶│MySQL8.4 │──切换─▶│MySQL8.4 │ │
│ │(生产) │ │(副本) │ │(就绪) │ │(新生产) │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │ │
│ └─────────────────┴─────────────────┴─────────────────┘ │
│ 持续数据同步 │
│ │
│ 耗时: 10-20分钟 耗时: 10-20分钟 耗时: ~4分钟 耗时: 1-5分钟 │
│ 业务影响: 零 业务影响: 零 业务影响: ~28秒断连 业务影响: 零 │
└─────────────────────────────────────────────────────────────────────────────┘
7.2 阶段 1:创建蓝绿部署
控制台操作
RDS 控制台 → 数据库 → 选择实例 → 操作 → 「创建蓝绿部署」

实例操作菜单 - 创建蓝绿部署
填写配置:
| 设置 | 值 |
|---|---|
| 蓝绿部署名称 | mysql80-to-84-upgrade |
| 源实例 | 自动填充选中的实例 |
| 目标引擎版本 | MySQL 8.4.x |
| DB 参数组 | 选择预创建的 MySQL 8.4 参数组 |






创建蓝绿部署配置页面
点击「创建蓝绿部署」。系统会自动完成以下任务:
- ✅ 创建源实例的读副本(绿环境,MySQL 8.0)
- ✅ 将绿环境升级到 MySQL 8.4
- ✅ 配置备份策略
CLI 命令参考:
bash
aws rds create-blue-green-deployment \
--blue-green-deployment-name mysql80-to-84-upgrade \
--source arn:aws:rds:<region>:<account>:db:<your-db-instance> \
--target-engine-version 8.4 \
--region <your-region>
返回示例
json
{
"BlueGreenDeployment": {
"BlueGreenDeploymentIdentifier": "bgd-xxxxxxxxxxxxx",
"Status": "PROVISIONING",
"Tasks": [
{"Name": "CREATING_READ_REPLICA_OF_SOURCE", "Status": "PENDING"},
{"Name": "DB_ENGINE_VERSION_UPGRADE", "Status": "PENDING"},
{"Name": "CONFIGURE_BACKUPS", "Status": "PENDING"}
]
}
}
7.3 阶段 2:监控部署进度
控制台查看
RDS 控制台 → 蓝绿部署 → 选择部署 → 查看状态




蓝绿部署状态页面 - 显示创建中/可用
状态流转:
plain
PROVISIONING → AVAILABLE → SWITCHOVER_IN_PROGRESS → SWITCHOVER_COMPLETED
各任务说明
| 任务 | 说明 | 预计耗时 |
|---|---|---|
CREATING_READ_REPLICA_OF_SOURCE |
创建源实例的读副本 | 10-20 分钟 |
DB_ENGINE_VERSION_UPGRADE |
升级绿环境到 8.4 | 10-20 分钟 |
CONFIGURE_BACKUPS |
配置备份策略 | 几分钟 |
⏱ 总耗时 :约 20-40 分钟 ,此阶段业务完全无影响。
CLI 命令参考:
bash
# 查看蓝绿部署状态
aws rds describe-blue-green-deployments \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
--region <your-region>
# 查看绿环境实例详情(实例名格式:{源实例名}-green-{随机字符})
aws rds describe-db-instances \
--db-instance-identifier <source-instance>-green-xxxxx \
--query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion}' \
--region <your-region>
绿环境预验证(关键步骤)
在部署状态变为 AVAILABLE 后,建议先对绿环境进行验证:
- 连接绿环境测试:
bash
mysql -h <green-instance-endpoint> -u admin -p -e "SELECT VERSION();"
- 检查复制延迟:
sql
-- 在绿环境上执行
SHOW REPLICA STATUS\G
-- 关注 Seconds_Behind_Master,确保接近 0
- 测试数据完整性:
sql
-- 对比行数
SELECT COUNT(*) FROM core_business_table;
- 运行应用兼容性测试:
- 使用 UAT/预发环境连接到绿环境
- 运行核心业务场景测试
7.4 阶段 3:执行切换(Switchover)
⚠️ 执行切换前,请确保:
- 部署状态为 AVAILABLE
- 复制延迟接近 0 (
Seconds_Behind_Master = 0)- 已完成绿环境应用兼容性测试
- 已通知相关团队
控制台操作
RDS 控制台 → 蓝绿部署 → 选择部署 → 操作 → 「切换蓝绿部署」


蓝绿部署 - 切换操作按钮
填写切换超时时间(建议保持默认 300 秒):
| 设置 | 说明 | 建议值 |
|---|---|---|
| 切换超时 | 等待数据同步追平的最长时间 | 300 秒 |


切换超时设置页面
点击「切换并确认」。
CLI 命令参考:
bash
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
--switchover-timeout 300 \
--region <your-region>
切换过程详解
以下基于实际测试数据的切换时间线(仅供参考,实际时间因实例配置而异):
plain
切换时间线(实测数据):
────────────────────────────────────────────────────────────────
08:33:35 切换开始,TPS 正常 (~263 tps)
08:33:51 TPS 开始下降,出现写入错误 (err/s: 142)
08:33:52 TPS=0,写入完全阻塞
08:36:47 连接完全中断 (QPS=0)
08:37:00 DNS 切换完成
08:37:30 切换完成,连接恢复
────────────────────────────────────────────────────────────────
⏱ 总切换时间: ~4 分钟
💥 完全断连时间: ~28 秒
📦 数据丢失量: 0
切换期间的实例名称变化
plain
切换前:
mysql-prod → MySQL 8.0(生产,蓝环境)
mysql-prod-green-xxx → MySQL 8.4(绿环境,副本)
切换后:
mysql-prod → MySQL 8.4 ✓(新生产,原绿环境提升)
mysql-prod-old1 → MySQL 8.0(原生产,可用于回滚)
重点 :切换完成后,原实例的 endpoint/CNAME 保持不变,应用无需修改连接字符串。


切换后实例列表 - 显示蓝色实例已变更为 8.4
7.5 阶段 4:验证与清理
验证切换状态
控制台查看:
RDS 控制台 → 蓝绿部署 → 确认状态为 SWITCHOVER_COMPLETED

蓝绿部署状态 - 显示 SWITCHOVER_COMPLETED
验证新版本
bash
mysql -h <your-rds-endpoint> -u admin -p -e "SELECT VERSION();"
清理资源
确认新版本运行正常后,清理蓝绿部署资源:
控制台操作:
RDS 控制台 → 蓝绿部署 → 选中 → 操作 → 删除


删除蓝绿部署页面 - 保留/删除旧实例选项

可选删除旧实例
CLI 命令参考:
bash
# 保留旧实例(推荐,保留回滚能力 24-48 小时)
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
--region <your-region>
# 确认后再手动删除旧实例
aws rds delete-db-instance \
--db-instance-identifier <your-db-instance>-old1 \
--skip-final-snapshot \
--region <your-region>
8. 升级后验证
8.1 版本确认
sql
SELECT @@VERSION, @@VERSION_COMMENT;
8.2 检查关键参数
sql
-- 检查认证插件相关
SELECT user, host, plugin FROM mysql.user;
-- 检查 authentication_policy
SHOW VARIABLES LIKE 'authentication_policy';
-- 检查 IO 相关参数
SHOW VARIABLES LIKE 'innodb_io_capacity%';
-- 检查日志缓冲
SHOW VARIABLES LIKE 'innodb_log_buffer_size';
8.3 检查复制状态(如果有关联只读副本)
sql
SHOW REPLICA STATUS\G
-- 确认 Slave_IO_Running = Yes, Slave_SQL_Running = Yes
8.4 功能验证清单
| 验证项 | 预期结果 | 状态 |
|---|---|---|
| 应用连接正常 | ✅ 连接成功 | □ |
| 读写功能正常 | ✅ CRUD 操作正常 | □ |
| 存储过程/函数正常 | ✅ 执行无报错 | □ |
| 备份正常 | ✅ 手动快照成功 | □ |
| 监控告警正常 | ✅ CloudWatch 指标正常 | □ |
8.5 性能对比(可选)
升级后建议对比升级前后的关键性能指标:
| 指标 | 升级前 (8.0) | 升级后 (8.4) | 变化 |
|---|---|---|---|
| TPS | --- | --- | --- % |
| QPS | --- | --- | --- % |
| 95% 延迟 | --- | --- | --- % |
| 连接数 | --- | --- | --- % |
9. 回滚方案
9.1 方法一:蓝绿切换回滚(推荐,仅限部署未删除前)
如果升级后发现问题,且蓝绿部署尚未删除:
bash
# 方法 1:再次执行蓝绿切换,切回旧实例
# 旧实例(-old1)此时仍为 MySQL 8.0,可被识别为新的绿环境
# 但注意:此方法在 AWS 控制台操作可能受限
控制台操作:
RDS 控制台 → 修改应用连接字符串,指向旧实例 endpoint
9.2 方法二:修改应用连接指向旧实例
切换完成后,旧实例被重命名为 {实例名}-old1(版本为 8.0):
plain
# 旧实例 endpoint
<your-db-instance>-old1.xxxxxxxxxxxx.<region>.rds.amazonaws.com
修改应用的数据库连接字符串指向这个旧实例即可快速回滚。
9.3 方法三:从快照恢复(通用回滚方案)
bash
# 从升级前创建的快照恢复
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier <your-db-instance>-rollback \
--db-snapshot-identifier pre-upgrade-snapshot-202607 \
--region <your-region>
10. 案例测试:模拟真实业务升级
10.1 测试环境配置
| 项目 | 配置 |
|---|---|
| 源实例 | RDS MySQL 8.0.40, db.r7g.large, Multi-AZ |
| 目标版本 | RDS MySQL 8.4.x |
| 升级方式 | 蓝绿部署 |
| 测试工具 | sysbench 1.0.20 |
| 测试数据 | 250 张表 × 25,000 行/表 |
| 区域 | ap-southeast-1 |
10.2 模拟业务负载
在升级过程中,使用 sysbench 持续产生读写负载,模拟真实业务场景:
bash
# 准备测试数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=<your-rds-endpoint> \
--mysql-user=admin \
--mysql-password=<password> \
--mysql-db=sbtest \
--tables=250 \
--table-size=25000 \
--threads=8 \
prepare
# 运行持续负载(在升级全程保持运行)
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=<your-rds-endpoint> \
--mysql-user=admin \
--mysql-password=<password> \
--mysql-db=sbtest \
--tables=250 \
--table-size=25000 \
--threads=8 \
--time=3600 \
--report-interval=10 \
run
10.3 实时健康检查
另外开启两个终端窗口,分别监控读写健康状态:
bash
# 终端 1:持续监控数据库版本和状态
while true; do
mysql -h <your-rds-endpoint> -u admin -p"<password>" \
-e "SELECT NOW(), @@hostname, @@VERSION, @@global.innodb_read_only;" \
-s -N 2>/dev/null
sleep 1
done
# 终端 2:持续写入监控
while true; do
mysql -h <your-rds-endpoint> -u admin -p"<password>" \
sbtest -e "INSERT IGNORE INTO sbtest1(k, c, pad) VALUES(1, 'health-check', 'test-123456');" \
2>/dev/null
sleep 1
done
10.4 执行升级
按照本文第 7 节的步骤执行蓝绿部署升级。
10.5 记录关键时间点
使用脚本自动记录各个事件的时间戳:
bash
# 切换开始
echo "$(date) - 开始执行切换" >> upgrade_timeline.log
# 定期监控状态(每 5 秒)
while true; do
STATUS=$(aws rds describe-blue-green-deployments \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
--query 'BlueGreenDeployments[0].Status' \
--output text \
--region <your-region> 2>/dev/null)
echo "$(date) - 状态: $STATUS" >> upgrade_timeline.log
sleep 5
done
10.6 测试预期结果
| 阶段 | 预期 | 验证方式 |
|---|---|---|
| 创建蓝绿部署 | 约 20-40 分钟,业务无影响 | sysbench 持续运行无报错 |
| 绿环境可用 | 可连接并查询数据 | 直接连接绿环境 endpoint |
| 切换开始 | TPS 开始下降 | sysbench 报告 TPS 归零 |
| 切换完成 | DNS 切换后连接恢复 | sysbench 重新开始计数 |
| 完全断连 | 预计 < 30 秒 | 健康检查脚本无响应时间 |
| 验证版本 | MySQL 8.4.x | SELECT VERSION() |
| 数据完整性 | 无数据丢失 | 对比行数/checksum |
10.7 清理测试资源
bash
# 删除蓝绿部署
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier bgd-xxxxxxxxxxxxx \
--region <your-region>
# 可选:删除旧实例
aws rds delete-db-instance \
--db-instance-identifier <your-db-instance>-old1 \
--skip-final-snapshot \
--region <your-region>
# 如果不再需要:删除测试数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=<your-rds-endpoint> \
--mysql-user=admin \
--mysql-password=<password> \
--mysql-db=sbtest \
cleanup
11. 总结与最佳实践
11.1 升级决策树
plain
┌─────────────────────┐
│ 准备升级 RDS MySQL │
│ 8.0 → 8.4 │
└─────────┬───────────┘
│
▼
┌─────────────────────────┐
│ ✅ 完成兼容性检查 │
│ ✅ 创建自定义参数组 │
│ ✅ 检查认证插件兼容 │
│ ✅ 备份 + 快照 │
└─────────┬───────────────┘
│
▼
┌─────────────────────────┐
│ 选择升级方法 │
│ │
│ 生产环境?──→ 蓝绿部署 │
│ 开发/测试?──→ 就地升级 │
└─────────┬───────────────┘
│
▼
┌─────────────────────────┐
│ 执行升级 │
│ 验证运行状况 │
│ 观察 24-48 小时 │
└─────────┬───────────────┘
│
▼
┌─────────────────────────┐
│ ✅ 升级完成 │
│ 🗑️ 清理蓝绿部署资源 │
│ 📝 更新运维文档 │
└─────────────────────────┘
11.2 最佳实践清单
时间选择
- ✅ 选择业务低峰期执行切换
- ✅ 预留足够的监控和回滚时间(至少 2-4 小时)
- ✅ 避免在节假日前夕操作
测试验证
- ✅ 务必先在测试环境完整演练一次
- ✅ 升级前在测试环境运行应用的全部集成测试
- ✅ 验证参数配置在 8.4 中的兼容性
性能优化
- ✅ 升级后根据磁盘 IOPS 优化
innodb_io_capacity和innodb_io_capacity_max - ✅ 考虑在升级时切换到 Graviton3/4 实例
- ✅ 对于需要减少升级频率的业务,考虑迁移到 Aurora LTS 版本
监控与通知
- ✅ 提前配置 CloudWatch 告警
- ✅ 准备实时监控脚本(读写健康检查)
- ✅ 提前通知所有相关团队
回滚保障
- ✅ 保留旧实例至少 24-48 小时
- ✅ 保留升级前的快照至少 7 天
- ✅ 准备书面的回滚流程和脚本
11.3 关键警示
🔴 最常出问题的地方:
- 认证插件不兼容 --- 升级前务必检查客户端库是否支持
caching_sha2_password- innodb_io_capacity 过高 --- 8.4 默认值 10000,如果磁盘 IOPS 不足会导致高并发写性能下降 7%-22%
- 复制参数 change MASTER → SOURCE --- 如果使用外部复制,需更新脚本
- 旧版客户端不支持 --- MySQL Connector/J 等旧版客户端需要升级
12. 参考资料
官方文档
系列参考文章
- 保驾护航系列 -- Amazon RDS for MySQL 5.7 到 8.0 升级方案
- RDS MySQL 8.0 版本升级指南 --- 亚马逊 AWS 官方博客
- AWS RDS MySQL 蓝绿部署升级完整指南 --- plantegg
- 使用系统双写和数据补全实现 Aurora MySQL 零停机升级
- Best Practices for Upgrading Amazon RDS for MySQL and Amazon RDS for MariaDB
反馈与建议
如果您在阅读本文过程中有任何问题或建议,欢迎留言讨论。如果您在实际升级中遇到了本文未覆盖的问题,也欢迎分享您的经验。