AWS RDS for MySQL 5.7升级到 8.0

 新钛云服已累计为您分享787篇技术干货

01

为什么要升级？

MySQL 5.7 的社区官方宣布这两个版本的生命周期结束（End-of-life，简称EOL），日期是2023年10月31日。

• MySQL 5.7停止维护会造成的影响如下：

1.会产生额外费用

AWS RDS MySQL 5.7 不会自动强制升级到8.0，但是会在 2024年3月1日强制升级到5.7.44，然后自动启用Extend Support，产生额外费用。具体收费情况，请参考官方文档https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support.html

2.存在安全风险

在结束生命周期后，社区将不会发布进一步的更新、错误修复或安全补丁，继续使用老版本可能会因为软件存在安全漏洞而影响到数据安全，可能会造成系统被攻击，数据泄漏等。

• Amazon RDS for MySQL 8.0 提供的新功能：
  

1.多可用区集群

一个写节点两个读节点的架构，使得三个节点都能对外提供服务，提高资源利用率；通过 SSD 存储内部 Log 以及多数节点完成落盘操作即可返回的技术，能够提高性能，减少故障恢复时间。

2.写入优化

利用 Nitro 硬件的优势，一次性将 16KiB 大小的数据页从内存写到数据文件中，避免了 MySQL 的双写机制，提升吞吐量，降低延迟，能够在相同配置环境下提供更高的吞吐量。

3.读取优化

利用实例自带的 SSD 盘进行临时表的存储，能够加速占用较大临时表空间查询的处理。

4.AURORA SERVERLESS V2

适合不确定的业务负载，高峰和低峰流量差别巨大的负载（差别10倍以上）。可实现数分钟内容量缩放不影响业务正常调用。最终获得成本节约。

详细信息参考官方文档:

https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html

02

升级前置条件

条件一：创建新的参数组

参数组类型

1、DB Parameter Group（数据库参数组）：DB Parameter Group是用于管理单个数据库实例的参数集合。每个数据库实例（如Amazon RDS中的MySQL、PostgreSQL、Oracle或SQL Server实例）都可以关联一个DB Parameter Group。该参数组中包含了用于控制数据库引擎行为和性能的多个参数。您可以创建、修改和应用DB Parameter Group来自定义和配置这些参数。对DB Parameter Group的更改将立即应用于关联的数据库实例。

2、DB Cluster Parameter Group（数据库集群参数组）：DB Cluster Parameter Group是用于管理数据库集群（如Amazon Aurora）的参数集合。数据库集群由多个数据库实例组成，这些实例共享相同的参数组。与DB Parameter Group不同，DB Cluster Parameter Group中的参数适用于整个数据库集群，而不仅仅是单个实例。对DB Cluster Parameter Group的更改将在数据库集群中的所有实例上生效。

条件二：选择升级方法

1.原地升级

原地升级。直接在数据库上点击，更改成新的 8.0 版本。操作简单，可能停机时间稍长。此外，为保证能够成功回溯，建议在升级以前先打个快照。一旦升级过程中出现问题，可以将快照恢复到一个新的数据库，将生产环境指向新库，以防对生产环境影响时间过长。

2.蓝绿切换自动升级

蓝绿部署自动化升级。利用 Amazon 提供的蓝绿部署升级工具，创建对应生产环境的绿集群，监控复制延迟，然后点击 switchover 进行升级。自动化蓝绿部署工具会自动切换 endpoint 信息，所以您无需更改应用程序指向集群链接。操作简单，停机时间很短，但蓝绿部署会按量收费。详细信息参考官方文档：https://aws.amazon.com/cn/quickstart/architecture/blue-green-deployment/

3.只读副本切换升级

创建 RDS 的一个只读副本，将只读副本升级成目标版本 8.0，等待复制延迟较低时，将只读副本 promote 成单独集群，再更改应用程序指向新的集群。操作简单，停机时间较短。

升级方法对比

03

升级方案

方案一：原地升级

在数据库控制台点击修改按钮

选择版本

选择参数组

立即升级

方案二：蓝绿切换自动升级

创建蓝绿部署

创建时可能遇到的问题

• 问题1：在参数组中未启用二进制日志输出（binlog_format ⇒ MIXED）

蓝绿部署需要集群参数组启用 binlog。该功能涉及使用二进制日志进行复制，因此必须启用二进制日志输出。由于 binlog_format 包含在集群的参数组设置中，因此您需要将该设置设置为 MIXED。如果不这样做，就会出现如下错误。

Blue Green Deployments requires cluster parameter group has binlog enabled.

• 问题2：更改参数组后未重新应用(重启)

如果在更改蓝色环境侧的集群参数组后(例如应用类型为静态时)尝试使用此功能创建绿色环境，可能会出现以下错误.

Blue Green Deployments requires writer instance to be in-sync with cluster parameter group.

切换

切换完成后，原“绿”库变为了现在的主库（蓝库）并保留了原主库的 endpoint 地址，之前的“蓝”库被重命名为“old1”。

根据您的业务情况观察一段时间，确认正常运行后，可以尝试删除old库以节约资源和成本

方案三：只读副本切换升级

只读副本进行升级的方式核心：通过提升原只读副本为主库的方式来实现快速切换，减少数据库升级的影响。（若没有只读副本可以创建一个）

升级只读副本

与原地升级的升级过程相同，在数据库控制台点击修改按钮，选择8版本，选择参数组，然后升级。

提升只读数据库为主库

04

总结

RDS MySQL 和Aurora MySQL的升级步骤大致相同，就不展开讨论了。从安全性角度考虑，5.7到8.0的升级，不仅可以提高系统的安全性能，还可以增强系统的稳定性和可靠性。从功能角度考虑，8.0提供了多可用区集群、写入优化、读取优化、以及AURORA SERVERLESS V2等新的功能，也具有较大的性能、可用性、弹性扩展优势，值得升级。综上所述，从安全性和功能角度考虑，5.7到8.0的升级是必要的，也是势在必行的！

如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。

参考资料

    推荐阅读   

    推荐视频