亚马逊AWS官方博客
RDS MySQL 8.0 版本升级指南
 |
一、前言
Amazon RDS for MySQL 是亚马逊云科技提供的完全托管的 MySQL 数据库服务，自动处理硬件配置、数据库设置、补丁更新和备份等运维任务，让您专注于应用程序开发而无需管理数据库基础设施。随着 MySQL 8.0 宣布支持标准周期的结束计划和 MySQL 8.4 系列功能的不断成熟，越来越多的企业开始考虑将生产环境迁移至MySQL 8.4，以此提供更稳定、更高效的数据库服务。
在这篇博文中，我们将讨论从 Amazon RDS MySQL 8.0 升级到 8.4 的实践，包括标准支持终止时间表，新版本特性变化，升级方案以及常见问题，帮助您平稳地完成数据库升级。
二、版本生命周期
Amazon RDS for MySQL 8.0 计划于 2026 年 7 月 30 日终止标准支持。我们建议您在 2026 年 7 月 30 日之前，尽早将数据库升级到 Amazon RDS for MySQL 8.4 的默认次要版本或更高版本。
在 RDS 标准支持终止日期之后，如果您在创建或还原数据库实例期间没有禁用 RDS 扩展支持，则 Amazon RDS 会自动将它们注册到 RDS 扩展支持，并收取相应的费用。如果您尚未运行在 RDS 标准支持终止日期之前发布的最后一个次要版本，Amazon RDS 会自动将您的数据库实例升级到该次要版本。关于扩展支持的详细信息，请参考文档：RDS 扩展支持说明。
 |
更多版本生命周期信息，请参阅：Amazon RDS 上支持的 MySQL 主要版本。
三、AWS RDS MySQL 8.4 主要特性变化
基于 MySQL 社区版 Release Notes，以下是 MySQL 8.4 相比 8.0 的主要特性变化：
认证插件变化
- mysql_native_password 默认禁用：从4.0 开始，mysql_native_password 认证插件默认不再启用
- authentication_policy 参数：默认值为 “:caching_sha2_password”，所有新用户默认使用更安全的认证方式
新增权限
- FLUSH_PRIVILEGES 权限：专门用于 FLUSH PRIVILEGES 语句
- OPTIMIZE_LOCAL_TABLE 权限：用于本地表优化操作
- TRANSACTION_GTID_TAG 权限：用于 GTID 标签功能
安全改进
- 弱密码套件移除：不再支持不符合安全标准的加密套件
- 证书验证增强：新增 tls-certificates-enforced-validation 系统变量
- LDAP 认证超时：新增连接和响应超时配置
性能优化
- IO 容量：innodb_io_capacity 从 200 提升到 10000
- 日志缓冲区：innodb_log_buffer_size 从 16MB 增加到 64MB
- 刷新方法：Linux 上默认使用 O_DIRECT
- 自适应哈希索引：默认关闭以提高性能
- 变更缓冲：默认设为 none
- 集合操作优化：EXCEPT 和 INTERSECT 使用新的哈希表优化
- 直方图自动更新：支持在 ANALYZE TABLE 时自动更新直方图
- 标量相关子查询优化：扩展了转换为派生表的支持
移除的选型和变量
- binlog_transaction_dependency_tracking
- default_authentication_plugin（使用 authentication_policy 替代）
- expire_logs_days（二进制配置方式参考：设置和显示二进制日志配置）
- 从基于 Binlog 复制的语句中把 MASTER 关键字修改为 SOURCE，参考文档：配置、停止二进制日志复制
新功能 – SQL 增强
- EXPLAIN 改进：支持 FORMAT=JSON INTO 和 FOR SCHEMA 选项
- SHOW PARSE_TREE：调试用的解析树显示（仅调试版本）
四、升级方案
从 MySQL 8.0 到 MySQL 8.4 属于主要版本升级，当您开始从 MySQL 8.0 更新到 8.4 时，Amazon RDS 会自动运行预检查，以便检测这些不兼容性，请提前参考RDS for MySQL 的主要版本升级文档确认必要的预检查项目，避免升级失败。
亚马逊云客户为客户提供了多种引擎版本升级方案，接下面我们将会对比就地升级和蓝绿升级两个常见的方案适用场景以及优劣分析，详细操作步骤建议参考我们系列博客 保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级方案。如果您希望完全零停机的数据库版本升级，则需要配合应用双写等方案共同完成，可以参考博客 使用系统双写和数据补全实现 Aurora MySQL 零停机升级。
 |
点击图片可查看完整电子表格
通过 Amazon Q CLI 简化大量集群升级
Amazon Q CLI 是一个由人工智能驱动的命令行界面工具，专为开发者和DevOps工程师设计。它基于Claude大语言模型，能够帮助用户通过自然语言对话的方式与AWS服务进行交互，执行各种开发和运维任务。该工具支持数百种流行的CLI命令（如git、npm、docker、aws等）的智能补全，可以理解用户的代码库环境，协助读写本地文件、查询AWS资源、编写代码以及自动调试问题，从而显著提升开发效率和简化AWS资源管理流程。
接下来是一个利用 Amazon Q CLI 自动化批量数据库蓝绿升级的示例：
[1] 下图为使用 Amazon Q CLI 开发一系列自动化脚本，包括：获取待升级的数据库列表、批量创建蓝绿部署、批量切换蓝绿部署、切换后批量健康检查几个核心步骤，具体的 prompt 建议根据实际情况调整。
 |
[2] 在 Amazon Q CLI 开发完脚本之后，进行必要的依赖包安装。
注意：在执行脚本的服务器上使用 aws configure 配置正确的 CLI 所需要的 Access Key、Secret Key 等信息。
 |
[3] 执行批量创建蓝绿部署脚本。
注意：请务必先在测试环境验证代码功能准确性！如果此环节遇到了异常，可以继续使用 Q CLI 进行脚本代码优化。
 |
[4] 执行批量切换蓝绿部署脚本。
 |
[5] 等切换完成之后进行健康检查，确定所有的实例均已经完成切换并且处于健康状态。
下图为一个异常示例，当蓝绿切换完成之后，如果旧实例上仍然存在业务连接，需要业务侧进一步检查是否因为 DNS 缓存等原因导致业务流量并未完全转移。
 |
[6] 最后，在控制检查这些已经完成切换的实例，与脚本处理的结果一致。
 |
五、回滚方案
 |
点击图片可查看完整电子表格
六、常见问题
authentication_policy 默认值变化导致程序连接失败
原因
在 AWS RDS MySQL 从 8.0 升级到 8.4 的过程中，authentication_policy 参数配置发生了变化，从之前的配置调整为 “:caching_sha2_password”，这意味着所有新创建的用户将默认使用 caching_sha2_password 认证插件。
潜在影响
- 应用程序连接失败
- 使用旧版本客户端库的应用程序可能无法连接数据库
- 出现类似错误：Authentication plugin ‘caching_sha2_password’ cannot be loaded
- 受影响的客户端库版本
- MySQL Connector/J < 8.0.9
- PHP mysqli/PDO < 7.4
- Python PyMySQL < 0.9.0
- js mysql2 < 1.6.0
- 旧版本 MySQL 命令行工具
- SSL 连接要求
- caching_sha2_password 需要 SSL/TLS 连接或 RSA 密钥交换
- 可能导致非 SSL 连接的应用程序无法正常工作
解决方案
方案1：修改现有用户认证方式（影响存量用户）
SELECT user, host, plugin FROM mysql.user WHERE user = ‘your_username’;
ALTER USER ‘your_username’@’%’ IDENTIFIED WITH mysql_native_password BY ‘your_password’;
FLUSH PRIVILEGES;
方案2：修改 RDS 参数组全局配置，使用旧的认证方式（影响后续新建的用户）
- 在 AWS 控制台进入 RDS → Parameter groups
- 修改 authentication_policy 参数为：*:mysql_native_password
- 应用参数组到 RDS 实例并重启
方案3：升级客户端库（长期方案）
- 升级应用程序使用的数据库客户端库到支持 caching_sha2_password 的版本，以获得更好的安全性。
七、性能对比
性能变化也是版本变更需要考量的一个重要维度，以下是使用 sysbench 1.0.20 跨 AZ 对 r7g.large 多可用区实例进行基准性能测试结果，测试数据集大小为 250 张表，每张表 25000 行数据，使用默认参数配置。
性能总结
在合理配置的参数下，从 RDS MySQL 8.0 升级到 RDS MySQL 8.4 之后，中低并发场景可以获得小幅度性能提升，而在其他场景下，性能基本和旧版本持平。
注意：基准性能测试结论不代表真实线上业务负载结果，升级之前请以实际业务负载测试结论作为判断依据。
 |
 |
进过分析，我们发现升级到 RDS MySQL 8.4 ，在 sysbench 测试场景下，读取性能在低并发场景下提升 20%+， 高并发下基本持平，但写请求的性能在高并发场景性能下降 7%-22%。这主要是因为在 RDS MySQL 8.4 中，一些参数默认值发生了变化，在本次测试场景中，升级后 innodb_io_capacity 从 200 变为 10000，而 innodb_io_capacity_max 从 2000 变为 20000，如果磁盘本身的 IOPS （gp3 默认 3000 IOPS）低于配置值，会导致在高并发下写请求的延迟显著增高。建议升级前根据自身的磁盘配置的 IOPS 对这两个参数进行优化，优化后的写请求吞吐量得到了提升，见图中的绿色柱状体。
对于其他参数默认值的变化，请参考附录中“参数默认值变化列表”。
 |
八、升级建议
- 确认升级前后的参数变化，在测试环境充分验证后再执行线上环境升级行为。
- 对于需要更高性能或性价比的场景，推荐在升级的过程中切换到 Graviton3/4 实例。
- 对于需要减少升级频率的业务数据库，可以考虑迁移到 Aurora LTS 版本。
九、附录
参数默认值变化列表
 |
点击图片可查看完整电子表格
相关内容推荐
数据库升级
- Amazon RDS 上支持的 MySQL 主要版本
- MySQL Release Notes
- RDS 扩展支持
- RDS for MySQL 的主要版本升级
- 蓝绿部署说明文档
- 系列博客：Aurora MySQL 升级检查
- 系列博客：保驾护航 – Amazon RDS for MySQL 5.7 到0 升级方案
数据库产品最新动态
- Amazon Aurora 现在支持基于 Graviton4 的 R8g 数据库实例
- 亚马逊云科技中国区域推出 CloudWatch 数据库洞察
- Amazon Aurora MySQL 3.10.1（与 MySQL 8.0.42 兼容）现已在亚马逊云科技中国区域正式推出
- Amazon Aurora Serverless 的收缩至零容量功能现可用于亚马逊云科技中国区域
- Amazon Aurora Serverless v2 现在在亚马逊云科技中国区域支持多达 256 个 ACU
- Amazon Aurora MySQL 和 PostgreSQL 现在在亚马逊云科技中国区域支持 R7g 数据库实例
- 全新 Graviton4 实例，提升 Valkey 性价比
其他产品和服务推荐
- S-BGP 是我们在由光环新网运营的亚马逊云科技中国（北京）区域和由西云数据运营的亚马逊云科技中国（宁夏）区域推出的一项成本优化型网络服务，旨在帮助我们的客户降低经过互联网传输数据出云（Data Transfer Out）的费用。 如果您想申请亚马逊云科技中国区域的 S-BGP 服务，请联系您的客户经理获取进一步帮助。
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。