1. 前言
MySQL 是流行的开源关系数据库，Amazon RDS for MySQL 使在云中更容易设置、操作和扩展 MySQL 部署。使用 Amazon RDS，您可以在几分钟内部署可伸缩的 MySQL 服务器，获得可调整的硬件容量以及成本效益。Amazon RDS for MySQL 可以管理备份、升级、软件修补、性能增强、监控、扩展和复制等耗时的数据库管理任务，让您能专注于应用程序开发。
1.1 为什么要升级
Amazon RDS for MySQL 不断和社区版本兼容，并和社区版本同步更新升级策略。出于以下几个方向考虑，我们建议您及时更新您的数据库版本：
安全性：随着网络威胁的不断发展，亚马逊云科技定期发布安全更新，以解决新的漏洞并提高其服务的安全性。升级到最新版本的 Amazon RDS for MySQL 可以确保您的数据库防范已知的安全风险。
功能增强：Amazon RDS for MySQL 是一个完全托管的服务，这意味着亚马逊云科技负责向服务添加新功能和功能性的改进。升级到最新版本可能包括访问新功能或对现有功能的改进。本博客 3.1 小节列出了 Amazon RDS for MySQL 8.0 相对于 5.7 的功能改进。
性能：亚马逊云科技不断努力优化其服务以获得更好的性能。升级到最新版本的 Amazon RDS for MySQL 可能包括性能增强，如更快的查询执行或改进的数据传输速率。
错误修复：像任何软件一样，Amazon RDS for MySQL 可能包含会影响性能或引起其他问题的错误。升级到最新版本可以解决已知的错误或问题。
总的来说，升级到最新版本的 Amazon RDS for MySQL 可以提升您的数据库安全性，提供新功能支持，带来性能提升，以及修复一些错误等。
1.2 升级种类和时间
对于 MySQL，版本号的组织方式为版本 = X.Y.Z。在 Amazon RDS 术语中，X.Y 表示主要版本号，Z 是次要版本号。对应地，MySQL 数据库实例升级也有两种方式：
主要版本升级。主要版本升级可能包含不与现有应用程序向后兼容的数据库更改。因此，您必须手动为数据库实例执行主要版本升级。您可以通过修改数据库实例来启动主要版本升级。
次要版本升级。次要版本升级仅包括与现有应用程序向后兼容的更改。您可以通过修改数据库实例来手动启动次要版本升级。您也可以在创建或修改数据库实例时启用自动次要版本升级选项。这样做意味着数据库实例在 Amazon RDS 测试并批准新版本后会自动升级。
亚马逊会定期弃用主要或次要引擎版本。主要版本至少在相应社区版本的社区生命周期结束或该版本不再接收软件修复或安全更新之前可用。对于次要版本，我们通常会在该版本存在严重错误或安全问题（在更高的次要版本中已解决这些问题）时将其弃用。
目前 Amazon RDS for MySQL 支持的主要版本有 5.7 和 8.0，对应详细的次要版本以及终止服务日期参照链接
Amazon RDS 上的 MySQL 版本
。
因为 MySQL 升级尤其是主要版本的升级需要进行版本兼容性的检查。开源社区对 5.7 的版本支持到 2023 年 10 月，Amazon RDS for MySQL 也会在后续一段时间内停止对 5.7 的支持。本系列博客主要聚焦在 MySQL5.7 到 8.0 的主要版本升级，旨在为您在升级数据库过程中提供有效指导，包括：如何订阅查看升级通知，升级前进行预先检查、升级方案的选择、以及回退方案等。
2. 如何收到升级通知
当 Amazon RDS 弃用某个数据库引擎的次要版本后，Amazon 会在宣布弃用后提供三（3）个月的时间，之后再开始自动升级。这一时间结束后，仍在运行已弃用次要版本的所有实例均会安排在计划维护时段内自动升级到受支持的最新次要版本。当 Amazon RDS 弃用某个数据库引擎的主要版本后，Amazon 会在宣布弃用后提供至少六（6）个月的时间，以便您升级到受支持的主要版本。这一时间结束后，仍在运行已弃用版本的所有实例均会在计划维护时段内自动升级到下一个主要版本。
默认升级的通知会发送到账号的注册邮箱和
Amazon Personal Health Dashboard（PHD）
。您也可以通过在 RDS 所在的亚马逊云科技区域
创建 EventBridge 规则
的方式增加订阅邮件。
在配置 EventBridge 规则的过程中，请注意在 “事件模式” 下，选择 “事件源” – “Amazon Web Services”，选择 “Amazon Web Service” – “Health”，选择“事件类型” – “特定运行状况事件”，选择“特定服务” – “RDS”，选择“特定事件类型类别” – “accountNotification”，选择“任何事件类型代码”，选择“任何资源”创建适用于所有 RDS 资源的规则。
3. 升级准备
在升级前，您可以梳理使用的数据库信息，对每个数据库进行相应评估，包括版本兼容性、升级方案选择等。建议您对各个数据库分别处理。本篇博客主要对具体某个库的处理方案进行展开。
3.1 了解版本新功能
MySQL8.0 提供了很多
新功能
的支持。比如：1）Window function 窗口函数能够对表中的每一行及相关行进行处理，可以方便地查询组内信息，比如找到每个部门的 top 员工，查找销售表里每个销售截止到当前记录的销售业绩等等，能够降低您自己写应用程序的复杂度。2）Common Table Expressions 通用表表达式是一种临时表，使用“WITH”命令，可以执行递归查询，能够降低您写应用程序的复杂度。此外，如果“WITH”后的表被引用了多次，只需要进行一次处理，可以带来性能提升。3）不可见索引能够帮助您评估索引的有效性，如果把索引设成不可见生成查询计划并没有发现优化，就可以决定将不可见索引删除。
Amazon RDS for MySQL 8.0 提供了几个新的功能，主要包括：1）
多可用区集群
一个写节点两个读节点的架构，使得三个节点都能对外提供服务，提高资源利用率；通过 SSD 存储内部 Log 以及多数节点完成落盘操作即可返回的技术，能够提高性能，减少故障恢复时间。2）
写入优化
利用 Nitro 硬件的优势，一次性将 16KiB 大小的数据页从内存写到数据文件中，避免了 MySQL 的双写机制，提升吞吐量，降低延迟，能够在相同配置环境下提供更高的吞吐量。3）
读取优化
利用实例自带的 SSD 盘进行临时表的存储，能够加速占用较大临时表空间查询的处理。
3.2 版本兼容性检查
MySQL 8.0 与 MySQL 5.7 存在一定的不兼容性。在从 MySQL 5.7 升级到 MySQL 8.0 时，这些不兼容性可能会引起问题。您可以查阅
从 MySQL 5.7 升级到 8.0 的预检查
来了解不兼容的类别。
针对特定数据库，您可以选择两种不同的方式可以展开预检查：
对现有数据库的快照进行原地升级，查看升级日志。
选取一台 EC2，安装 MySQL 升级工具，运行该工具，查看不兼容的项。
两种方式都会进行预检查，判断您的数据库是否存在兼容性问题。RDS for MySQL 快照的方式会涵盖更加全面的信息，MySQL 升级工具能够免去打快照，进行尝试升级的时间。您可以根据需要进行选择。
关于具体的预检查方式、执行结果的解析以及相应修复方式，请参阅本系列博客
《保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级前置检查》
。
3.3 新版本功能、性能测试
在进行正式升级前，建议您做好充足测试。可以以模拟业务系统的流量的负载，将压力压在 8.0 集群上，评估功能、性能是否满足条件。如果不满足，需要在升级之前尽量做好调整。
3.4 升级方法评估选型
在进行真正升级时，有几种不同的升级方法可供您选择：
原地升级。直接在数据库上点击，更改成新的 8.0 版本。操作简单，可能停机时间稍长。此外，为保证能够成功回溯，建议在升级以前先打个快照。一旦升级过程中出现问题，可以将快照恢复到一个新的数据库，将生产环境指向新库，以防对生产环境影响时间过长。
只读副本升级。创建 RDS 的一个只读副本，将只读副本升级成目标版本 8.0，等待复制延迟较低时，将只读副本 promote 成单独集群，再更改应用程序指向新的集群。
蓝绿部署自动化升级
。利用 Amazon 提供的蓝绿部署升级工具，创建对应生产环境的绿集群，监控复制延迟，然后点击 switchover 进行升级。自动化蓝绿部署工具会自动切换 endpoint 信息，所以您无需更改应用程序指向集群链接。
手动蓝绿部署升级。自己创建一套绿环境，和蓝环境间搭建 binlog 复制机制，然后监控复制延迟。延迟较低时，对蓝环境停写，等待绿环境追平，将应用程序指向绿环境。
DMS 全量加增量升级。建立一个空的 8.0 集群，配置 DMS 的全量+增量升级，进行升级操作。可以参照
该文档
。
下面是几种升级方式的对比图：
升级复杂度
适用的数据集规模
1）提前打快照。因为 RDS 打快照是增量快照的方式，升级前提前打快照能够加速原地升级本身的时间
2）评估停机时间
只读副本升级
1）应用更改 Endpoint 连接。应用需要连接到新的数据库集群
2）副本提升后要生成和源集群相同拓扑
蓝绿部署自动化升级
1）如果 RDS 后有 binlog consumer，需要先停止复制，再蓝绿切换以后重新对外提供服务前拿绿环境上 binlog 文件和位移，再配置 consumer
2）监控复制延迟较小时再点击切换
手动蓝绿部署升级
1）应用更改 Endpoint 连接；
2）监控复制延迟较小时再点击切换
3）binlog filter 配置，建议 exclude 系统库，因为 8.0 和 5.7 的系统表可能不一致,在创建 binlog 复制时最好过滤掉。可以通过参数 replicate-do-db- 来配置需要同步的业务数据库，或者通过参数 replicate-ignore-db 来配置需要忽略的数据库(information_schema/mysql/performance_schema/sys)
DMS 全量加增量升级
较小数据量
1）DMS 正确配置
2）Binlog filter 配置，建议 exclude 系统库，因为 8.0 和 5.7 的系统表可能不一致,在创建 binlog 复制时最好过滤掉。可以通过 DMS 创建复制任务的时候通过
Selection rules
来指定需要复制的数据库
进行各种方案评估时，建议您运行一些负载，最好是与生产环境类似的负载，进行验证，包括方案的正确性，以及对应用程序中断时长的影响等。
下面是一个简单的判断写是否成功的示例：通过每隔 1 秒循环写请求数据库，判断数据库是否写入正常：
while true;
mysql -u admin -p"Abc12345" -h zk-upgrade-direct-5-7-33.xxx.rds.cn-northwest-1.amazonaws.com.cn zk -P 3306 -e "insert into user(name,age,city,sex,address,description) values(concat('user','1'), 1,2,0,'suzhou','description');"
echo -e "\n\n"
now=$(date +"%T")
echo "Current time : $now"
sleep 1
具体的各种升级方式的步骤以及大致影响，请参考本系列博客《保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级方案》。
3.5 创建新的参数组
在升级时，您需要为 8.0 选择合适的参数组。具体可以参考如下：
在控制台中，参照下图方法新建参数组，并将旧的参数信息移植到新的参数组中。需要注意选择对应的参数组系列和类型。
如果需要将原参数组的设置还原到新的参数组中，可以通过比较参数组的方式找回原参数组的配置，并在新的参数组中进行还原设置：
4. 升级回退方案
我们建议您在升级前做好充分测试，包括材料的归集以及重复的测试验证。如果前期准备充分，一般情况下真正升级过程中遇到问题几率很小。对于核心系统如果需要回滚方案，则可以按如下原则进行准备。
回滚方案分以下两种：
1. 原地升级失败回滚：如果是原位升级默认本身升级失败会回退，但强烈建议升级前手工打 5.7 集群的快照，如果升级失败没能自动回滚，那么就用快照恢复一个新的 5.7 集群，然后应用指向新的 5.7 集群完成回滚。回滚步骤：
1）对待升级集群打快照，保存快照
2）进行原地升级到 8.0
3）如果原地升级失败，自动回滚
4）如果步骤 3 没有成功，则使用步骤 1 的快照恢复一个新的 5.7 集群
5）应用指向新的 5.7 集群（需要修改程序访问的数据库连接信息）
2. 最小停机时间回滚：如果希望最小停机时间回滚，那么就需要 5.7 升级到 8.0 之后，应用切换写入到 8.0 新集群之前要开启 binlog，而后记录新集群 binlog 文件及位置，以该信息做一个反向 DMS CDC only 的 DMS 任务同步 8.0 数据回 5.7 集群，这样有问题可以切换回 5.7。 回滚步骤：
1）5.7 升级到 8.0 后，检查没有问题后，切断 5.7 和 8.0 新老数据库集群之间的数据复制
2）在应用程序往 8.0 新集群写入数据之前，开启 8.0 集群 binlog
3）记录 8.0 集群的 binlog 文件及位置
4）基于步骤 3，创建一个 DMS 同步任务将 8.0 集群变化数据同步回 5.7 集群
5）如果发现 8.0 集群有问题，确保将 8.0 集群上的更新数据同步到 5.7 集群，并将应用切回指向到 5.7 集群（需要修改程序访问的数据库连接信息）
在 DMS 创建反向同步任务时，需要注意仅仅配置需要同步的业务数据库，不要使用通配符。
5. 总结
Amazon RDS for MySQL 5.7 到 8.0 的升级非常重要，本篇博客介绍了升级的重要性，并阐述了如何进行升级前的前置检查，升级方案的评估选择，以及回退方案的制定。希望能够帮助您在升级的时候做出适合您场景的决策，利用到 MySQL 8.0 新特性的同时，也能够摒弃 5.7 后续可能的安全风险。
