AWS RDS MySQL 8.0 升级到 8.4 完整操作指南

AWS RDS MySQL 8.0 升级到 8.4 完整操作指南

作者: 指剑

日期: 2026 年 7 月

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


目录

  1. 前言
  2. 版本生命周期与升级必要性
  3. 升级前准备:兼容性检查清单
  4. [MySQL 8.4 主要变化与注意事项](#MySQL 8.4 主要变化与注意事项)
  5. 升级方案对比与选择
  6. 方案一:控制台就地升级
  7. 方案二:蓝绿部署升级(推荐)
  8. 升级后验证
  9. 回滚方案
  10. 案例测试:模拟真实业务升级
  11. 总结与最佳实践
  12. 参考资料

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 参数组

创建蓝绿部署配置页面

点击「创建蓝绿部署」。系统会自动完成以下任务:

  1. ✅ 创建源实例的读副本(绿环境,MySQL 8.0)
  2. ✅ 将绿环境升级到 MySQL 8.4
  3. ✅ 配置备份策略
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 后,建议先对绿环境进行验证:

  1. 连接绿环境测试:
bash 复制代码
mysql -h <green-instance-endpoint> -u admin -p -e "SELECT VERSION();"
  1. 检查复制延迟:
sql 复制代码
-- 在绿环境上执行
SHOW REPLICA STATUS\G
-- 关注 Seconds_Behind_Master,确保接近 0
  1. 测试数据完整性:
sql 复制代码
-- 对比行数
SELECT COUNT(*) FROM core_business_table;
  1. 运行应用兼容性测试:
    • 使用 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_capacityinnodb_io_capacity_max
  • ✅ 考虑在升级时切换到 Graviton3/4 实例
  • ✅ 对于需要减少升级频率的业务,考虑迁移到 Aurora LTS 版本
监控与通知
  • ✅ 提前配置 CloudWatch 告警
  • ✅ 准备实时监控脚本(读写健康检查)
  • ✅ 提前通知所有相关团队
回滚保障
  • 保留旧实例至少 24-48 小时
  • ✅ 保留升级前的快照至少 7 天
  • ✅ 准备书面的回滚流程和脚本

11.3 关键警示

🔴 最常出问题的地方:

  1. 认证插件不兼容 --- 升级前务必检查客户端库是否支持 caching_sha2_password
  2. innodb_io_capacity 过高 --- 8.4 默认值 10000,如果磁盘 IOPS 不足会导致高并发写性能下降 7%-22%
  3. 复制参数 change MASTER → SOURCE --- 如果使用外部复制,需更新脚本
  4. 旧版客户端不支持 --- MySQL Connector/J 等旧版客户端需要升级

12. 参考资料

官方文档

系列参考文章


反馈与建议

如果您在阅读本文过程中有任何问题或建议,欢迎留言讨论。如果您在实际升级中遇到了本文未覆盖的问题,也欢迎分享您的经验。

相关推荐
J-Tony1110 小时前
【Redis】 Redis 是单线程还是多线程
服务器·数据库·mysql
linux kernel10 小时前
02:库与表的操作
mysql
wuqingshun31415916 小时前
什么是代理模式?一般用在什么场景?
java·mysql·代理模式
程序员小八77717 小时前
从 0 学习 MySQL 索引——7 大核心精讲
android·学习·mysql
渣渣灰飞17 小时前
MySQL 系统学习 第六阶段:Redis + 缓存 + 高并发设计 第六章:Redis 实现登录 Token
学习·mysql·缓存
渣渣灰飞17 小时前
MySQL 系统学习 第六阶段:Redis + 缓存 + 高并发设计 第五章:缓存穿透、缓存击穿、缓存雪崩
学习·mysql·缓存
Soari17 小时前
【突发暴更】Claude Code v2.1.208 :无障碍辅助模式正式上线、Vim 连击热键出逃、大修内存泄漏与跨域 AWS SSO 登录崩溃!
编辑器·vim·aws·claude code
Rsun0455119 小时前
MySQL 中什么是回表?
数据库·mysql
xywww16821 小时前
AWS 账号安全加固:Root 与 IAM 用户的 MFA 设置实操清单
安全·云计算·aws