MySQL 5.7 社区在2023年10月31日End-of-lift结束生命周期。AWS RDS MySQL 5.7 不会自动强制升级到8.0，但是会在 2024年3月1日强制升级到5.7.44，然后自动启用Extend Support，产生额外费用。具体参考2023年12 月21日最新通知。
目录
- 一、什么需要升级
- 二、Deadline时间会发生什么
- 三、不想做版本升级的三种备选方案
- 四、是否将Extended Support延长支持作为客户首选方案
- 五、升级到8.0版本的好处
- 六、确定升级需要解决的应用代码兼容问题
- 七、几种升级方式
- 八、小结
- 九、可用资源和参考资料
一、什么需要升级、有多少需要升级
1、哪些数据库版本需要被升级
一句话概括：RDS MySQL 5.7和PostgreSQL 11.x需要在2024年3月1日之前完成大版本升级，否则会强制被升级到最新小版本且产生扩展支持的费用。Aurora MySQL 5.7可以在2024年从11月1日起强制升级到最新小版本且产生扩展支持费用。RDS和Aurora的8.0系列不受影响。
2、为何需要升级版本
MySQL 5.7和PostgreSQL 11的社区官方宣布这两个版本的生命周期结束（End-of-life，简称EOL），日期是2023年10月31日。
EOL是软件产品生命周期末尾最后一个环节。历史上，多个版本的Windows/SQL Server Database/Oracle Database这些都一样经过了这样的EOL，而使用这些旧版本软件的用户也逐步完成了到新版本的转换。而这一次，是使用非常广泛的MySQL 5.7和PostgreSQL 11来到了生命周期的结束。
3、不升级的隐患在哪里
在结束生命周期后，社区将不会发布进一步的更新、错误修复或安全补丁，继续使用老版本可能会因为软件存在安全漏洞而影响到数据安全，可能会造成系统被攻击，数据泄漏等。
例如某一个数据库被配置为在互联网上Public允许其他合作伙伴数据交互。当这个数据库版本不再获得补丁至此而存在漏洞之后，攻击者可能会通过发送特定请求代码给数据库，危及到数据库的安全，获取了不应该具有的权限，拿到了不应该拿到的数据，造成重大安全事件。
当数据库在内网时候，这个问题依然存在。攻击者可通过对应用服务器进行攻击，或借助应用服务器发送特殊的请求触达数据库。此时存在漏洞的数据库可能会崩溃，或者造成数据泄漏。
提问，MySQL真有那么多漏洞吗？请参考如下截图：
以上清单中，关联漏洞的公开资料如下：
https://cve.report/CVE-2023-22053
以上只是一部分漏洞的例子。因此，在数据库End-of-life（也就是EOL）结束生命周期后，一定要对其进行大版本升级。抛弃旧的版本，升级到能够继续获得补丁支持的版本，才能确保数据安全。
二、Deadline时间过了会发生什么
1、AWS RDS 停止支持时间
MySQL 5.7和PostgreSQL 11的社区生命周期结束是2023.10.31。过了这个时间什么也不会发生。
AWS云上的RDS服务给用户了一定的缓冲时间，其中：MySQL 5.7和PostgreSQL 11是2024年2月29日；Aurora MySQL 5.7 2024.10.31。
2、过了AWS RDS停止支持的时间节点，是否会发生强制升级
之前AWS的策略是强制从5.7升级到8.0。
为响应用户的呼声，2023年12月21日宣布将不会触发强制升级，但是：
- 低于5.7.44的RDS MySQL将会在2024年3月1日强制升级到RDS MySQL 5.7.44；
- RDS MySQL 5.7从2024年3月1日将自动开启Extended Support产生额外费用；
- Aurora 5.7的End-of-life在2024年10月31日，从2024年11月1日起会自动开启Extended Support产生额外费用。
三、不想做版本升级的三种备选方案
本文编写以MySQL 5.7为例，PostgreSQL 11升级的处理方式相同。
1、使用扩展支持计划 RDS/Aurora Extended Support
AWS为社区已经结束生命周期的MySQL 5.7和PostgreSQL 11提供了额外的延长支持，这个延长期内，AWS会继续提供定义为critical和high级别的CVEs安全补丁，重大缺陷的补丁修复和故障升级，并继续满足RDS服务的相关SLA。使用延长支持的前提是您必须将5.7系列小版本升级到最新小版本5.7.44。
从2023年12月1日起，RDS MySQL 5.7/RDS PostgreSQL 11用户可看到有关选项并订购本服务。在2023年12月1日之前，RDS控制台界面上将不会看到有关延长支持的选项。订购之后，服务的实际收费是从AWS产品End-of-life（即触发强制升级）的日期开始计算，也就是从2024年3月1日开始收费，并不是从延长支持选项在界面上可见并可操作订购的2023年12月1日当天计费。
如果您没有采取任何行动，那么从2024年3月1日起，您的现有的RDS MySQL 5.7将从现有小版本（例如5.7.38）强制升级到最新的小版本5.7.44（在指定的Maintain Window会经历一次重启），然后延长支持选项会自动打开。
使用本计划的方式、成本、以及最终决策建议，请参考本文下一章节。
2、从RDS MySQL 5.7 迁移到Aurora MySQL 5.7 LTS版本
由于Aurora MySQL 5.7在2024年10月31日才End-of-life，比RDS MySQL 5.7晚半年，因此您可以将目前的RDS MySQL 5.7升级到Aurora MySQL 5.7版本，这样即可继续停留在5.7版本，而无需解决5.7和8.0之间的兼容差异问题。
不过，由于Aurora MySQL和RDS MySQL是不同的服务，在AWS控制台上是独立的两个服务器集群、且各自有不同的Endpoint和流量入口，因此选择从RDS MySQL 5.7到Aurora MySQL 5.7这条路线，也需要事实上的做一次迁移，即将数据在两个集群间复制、同步，并在最后割接窗口切换流量的问题。这样看选择本路线技术上存在一定的复杂度，需要事先规划方案。此外，升级到Aurora 5.7，还涉及RDS的RI和Aurora的RI预留实例的变化等商务问题。
虽然从RDS MySQL 5.7更换为Aurora MySQL 5.7，可将结束生命周期的日志延长到1年到2024年10月31日，但在2024年10月31日之后还是会面临相同的问题，是升级到8.0彻底解决问题，还是停留在5.7版本开启Extended Support，还是返回EC2自建数据库集群等几个路线的选择。
由此，这个技术路线可作为备选，是否采用，请综合多种因素决策。
3、脱离RDS托管服务、迁移到EC2自建MySQL集群
继续停留在MySQL 5.7版本的另一个方式就是不再使用RDS MySQL 5.7，而是改用在EC2上自建MySQL集群的方式。
采用这种方式，要求开发或者运维团队能搭建有效的MySQL高可用集群，实现主从节点和只读节点之间的可靠数据复制，并具有健康检查和Failover切换能力。此外，自行搭建MySQL集群还需要考虑操作系统内存优化、文件系统读写优化、网络吞吐优化、监控数据采集、备份、快照、日志、审计等一系列特性。这一系列对大部分客户的技术团队构成了较大挑战。
此外，使用EC2自建MySQL集群，还涉及RDS的RI和EC2的RI预留实例的变化等商务问题。
由此，这条路线不推荐。
四、Extended Support延长支持服务介绍
1、延长支持的服务范围
AWS为社区已经结束生命周期的MySQL 5.7和PostgreSQL 11提供了额外的延长支持，这个延长期内，AWS会继续提供定义为critical和high级别的CVEs安全补丁（定义是CVSS v3评分大于7.0的缺陷），重大缺陷的补丁修复和故障升级，并继续满足RDS服务的相关SLA。
2、打开延长支持的小版本要求
需要注意的是，并不是任意版本的RDS MySQL 5.7、RDS PostgreSQL 11、以及Aurora 5.7都能获取延长支持。已经确认的将可以打开Extended Support的版本是：
- RDS for MySQL 5.7.44
- RDS for PostgreSQL 11.22
- Aurora MySQL 2.11 and 2.12
- Aurora PostgreSQL 11.9 (LTS) and 11.21 (last minor)
- Aurora Serverless v2
其他小版本将不能享受到延长支持。您需要先将低于以上小版本的数据库进行小版本，在开启延长支持前，满足以上小版本要求，然后才能打开延长支持。
3、延长支持启用时间
时间线：
- - 在2023年12月之前，RDS控制台界面上将不会看到有关延长支持的选项；
- - 从2023年12月起，RDS和Aurora用户可订购延长支持服务；
- - 从2024年3月1日起，还没升级的RDS MySQL 5.7和RDS ProsgreSQL 11自动开启延长支持
详细清单如下：
从2023年12月起，RDS和Aurora用户可订购延长支持服务。在2023年12月之前，RDS控制台界面上将不会看到有关延长支持的选项。
版本
开源社区
End-of-life
生命周期结束时间
Extended Support
延长服务可订购
AWS服务End-of-life
生命周期结束时间
自动开启延长服务
时间
Extended Support延长服务
开始计费时间
延长服务
第一份账单生成时间
RDS PostgreSQL 11
2023.10.31
2023.12.1
2024.2.29
2024.3.1
2024.3.1
2024.4.1
RDS MySQL 5.7
2023.10.31
2023.12.1
2024.2.29
2024.3.1
2024.3.1
2024.4.1
Aurora PostgreSQL 11
2023.10.31
2023.12.1
2024.2.29
2024.3.1
2024.3.1
2024.4.1
Aurora 5.7
2023.10.31
2023.12.1
2024.10.31
2024.11.1
2024.11.1
2024.12.1
4、官网Extended Support价格（全球区域）
RDS MySQL 5.7的价格入口：https://aws.amazon.com/rds/mysql/pricing/ ，定价：每小时 $0.120 每个vCPU。
Aurora MySQl 5.7的价格入口：https://aws.amazon.com/rds/aurora/pricing/ ，定价：每小时 $0.120 每个vCPU。
由此可以看到，RDS MySQL 5.7和Aurora MySQL 5.7的Extension Support的定价相同。
另外请注意，第一年和第二年定价是一个标准规格，第三年价格翻倍。
5、中国区域的Extended Support价格
中国区域定价请参考这里：https://www.amazonaws.cn/en/rds/pricing/
6、客户实际Case的成本提升的对比（本测算以海外为例）
这里以RDS MySQL 5.7和Aurora MySQL 5.7分别测算。
（1）RDS MySQL 5.7
使用m6g.4xlarge机型(16vCPU/64GB)，集群为Multi-AZ Deployment(1主1备)，在新加坡区域、典型的一年期、无预付RI的成本如下截图所示，每月$1588.48。
根据RDS Extended Support的定价，以第一年和第二年为例，每月价格为：$0.120 * 16vCPU * 2个节点 * 720小时 = $2764.8 USD 每月。
与RDS本身的RI相比，原先RI的价格是$1588.48，开启RDS Extended Support新价格是($1588.48+$2764.8)=$4353.28，价格提升了174%。由此可看出价格大幅上涨。
（2）Aurora MySQL 5.7
使用r6g.2xlarge机型(8vCPU/64GB)，集群为2台（1个Writer一个Reader)，在新加坡区域、典型的一年无预付RI的成本如下截图所示，每月$705.62*2=$1411.24。
根据RDS Extended Support的定价，以第一年和第二年为例，每月价格为：$0.120 * 8vCPU * 2个节点 * 720小时 = $1382.4 USD 每月。
与RDS本身的RI相比，原先RI的价格是$1411.24，新价格是($1411.24+$1382.4)=$2793.64，价格提升了98%。由此可看出价格大幅上涨。
6、关于RDS Extended Support的小结
上一个小标题对比RDS MySQL 5.7和Aurora MySQL 5.7场景，对比的机型内存都是64GB，但是因为RDS是m系列、Aurora是r系列，因此Aurora的CPU个数更少，由此按照vCPU计费的RDS Extended Support费用就相对低一点。However，即使如此，在Aurora开启Extended Support后价格上涨98%，提升了一倍。到第三年后，基础vCPU定价翻倍，因此成本会再次涨一大截。
由此，从成本节约角度，建议客户尽在最重要且时间来不及做应用兼容测试的集群上，开启Extended Support获得延期技术支持，然后尽快完成所有升级。最理想的，还是在2024年2月29日前完成兼容测试和升级，这样也就完全不用开启Extended Support了。
五、升级到8.0版本的好处
1、针对运维：RDS MySQL 8.0提供的新的基础功能（集群、可靠性、性能）
以下特性显著的提升了数据库的可用性、负载能力、弹性扩展能力，值得升级到8.0版本。
（1）新的RDS Multi-AZ Cluster 1主2读高可用集群
适合较多查询的业务场景，官方介绍：https://aws.amazon.com/cn/rds/features/multi-az/
（2）RDS 写入优化机型
在包括R5b、m6gd等机型上，实现超过2倍的写入性能提升。
官方发布：
官方文档：
https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/rds-optimized-writes.html
（3）RDS 读取优化机型
查询性能提升超过50%。
官方文档：
https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/rds-optimized-reads.html
（4）Aurora Serverless V2
适合不确定的业务负载，高峰和低峰流量差别巨大的负载（差别10倍以上）。可实现数分钟内容量缩放不影响业务正常调用。最终获得成本节约。
官方文档：
https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
(5) 新版本上提升3倍写入量
如果您运行的是 RDS for MySQL 8.0.34 版或更低版本，则可以升级到 RDS for MySQL 8.0.35 版，以享受性能改进带来的好处。我们建议您升级到最新的次要版本以修复早期 MySQL 版本中的已知安全漏洞，并受益于漏洞修复、性能改进及 MySQL 社群增加的新功能。详情参考这里。
2、针对开发：
- Multi-threaded replication：更好的Binlog复制性能
- 复制过滤：更精准的复制
- Binary log压缩（zstd）：更快的性能
- Instant DDL：快速变更表结构不影响业务写入
- 公用表表达式 (Common table expressions)：优雅简洁的开发
- 窗口函数：简化开发
- 新的索引类型：降序索引、不可见索引
- RBCA：Role-based权限控制
3、小结
基于以上新特性，升级到MySQL 8.0可带来可用性、性能、新语法等多种收益，因此建议升级到8.0版本。
六、确定5.7升级8.0需要解决的应用代码兼容问题
1、应用场景概述
常见云上数据库使用场景可分层三类：
（1）企业客户
企业内部系统，系统可能为外包开发采购，也可能是自开发。只包含增删查改逻辑，将数据库当成Excel用。
这部分客户从5.7版本升级到8.0版本几乎不需要任何代码调整。即使开发商不配合，或者开发团队没有时间精力修改，可考虑由运维团队Lead，部署新的8.0版本数据库，在不修改代码的情况下做业务功能验证测试。大部分应用可顺利迁移到8.0，无须改动代码。
（2）互联网类客户
通常系统为To-C端在线系统，交易量较大，使用只读节点读写分离，普遍使用BINLOG复制或者DMS复制等，将数据从OLTP库复制到OLAP的分析集群。
此类型客户，需要做兼容测试，主要挑战来自字符集、binlog的处理方式等适配工作，一般不需要改动代码。
（3）深度使用的数据库开发者用户
此类客户使用了包括存储过程、触发器、约束等大量数据库专有的技术且可能锁定了MySQL 5.7版本，更换到8.0版本上可能需要较大改动。但是，此类用户的占比很小，大部分客户都不是本场景。
此类客户也需要兼容性测试和代码改动可能较多，预期花费时间较长。
2、一些常见的5.7版本升级到8.0版本的兼容问题
- 默认字符集问题：MySQL 8.0的默认字符集utf8mb4，可能会导致之前数据的字符集跟新建对象的字符集不一致，为了避免新旧对象字符集不一致的情况，可以在配置文件将字符集和校验规则设置为旧版本的字符集和校验规则。
- Lower_case_table_names：MySQL 8.0启动使用的lower_case_table_names值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题
- 存储引擎问题：InnoDB和NDB是唯一提供MySQL 8.0支持的本地分区处理程序的存储引擎。 如果分区表用的是别的存储引擎比如MyISAM，存储引擎必须进行修改。要么将其转换为InnoDB或NDB，要么删除其分区
- 密码加密方式：caching_sha2_password认证插件提供更多的密码加密方式，并且在加密方面具有更好的表现，目前MySQL 8.0选用caching_sha2_password作为默认的认证插件，MySQL 5.7的认证插件是MySQL_native_password。如果客户端版本过低，会造成无法识别MySQL 8.0的加密认证方式，最终导致连接问题
- Sql_mode系统变量：要避免MySQL 8.0上的启动失败，MySQL配置文件中的sql_mode系统变量不能包含NO_AUTO_CREATE_USER。
- SQL MODE：在MySQL 8.0中，删除了这些不推荐使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。从5.7到8.0的复制场景中，如果语句使用到废弃的SQL Mode会导致复制异常。
3、使用MySQL官方的兼容性检查工具进行诊断
MySQL 8.0新版提供了名为util.checkForServerUpgrade的工具，这个脚本随MySQL Shell软件包提供。
检查的项目包括：
1）旧的时间类型使用
2）类存储过程对象的 MySQL8.0 语法兼容检查
3）与新保留字、新关键字冲突的数据库对象名称使用
4）使用 utf8mb3 字符集
5）mysql 库中的表名与 8.0 中的新表冲突
6）使用非本地分区引擎的分区表
7）外键约束名超过 64 个字符
8）使用过时的 MAXDB sql_mode 标志
9）使用过时的 sql_mode 标志
10）ENUM/SET 列定义包含长度超过 255 个字符的元素
11）在共享表空间中使用分区表
12）表空间数据文件路径中的循环目录引用
13）使用已删除的函数
14）使用已删除的 GROUP BY ASC/DESC 语法
15）将错误日志记录到系统日志配置的已删除系统变量
16）已删除的系统变量
17）具有新默认值的系统变量
18）零日期、日期时间和时间戳值
19）由于文件移除或损坏导致的数据库结构不一致
20）InnoDB 识别的属于其他引擎的表
21）由'check table x for upgrade'命令报告的问题
22）新的默认身份验证插件注意事项
23）不能有默认值的列
24）检查在 5.7 中使用的无效表名和库名
25）检查 5.7 中的孤立存储过程
26）检查在对象名称中使用单美元符号的过时用法
以上检查结果将生成报告，用于评估必要的代码改动。
4、兼容性检查工具的使用方法
从Oracle官网（Oracle多年前收购了MySQL）下载最新的MySQL Shell软件包，本文编写时（2023年10月）最新版本是8.0.34。下载网址：
https://dev.mysql.com/downloads/shell/
请注意选择需要对应的OS、硬件架构（X86_64/ARM）的软件包。Amazon Linux 2可以选择Red Hat Enterprise Linux 7的软件包，Amazon Linux 2023选择Red Hat Enterprise Linux 9的软件包。
以一台使用Graviton处理器的t4g.medium的EC2，操作系统Amazon Linux 2023为例，下载后执行如下命令完成安装：
yum localinstall mysql-shell-8.0.34-1.el9.aarch64.rpm -y
安装完毕后，运行mysqlsh命令启动MySQL Shell，再执行如下命令进行兼容性检查（请替换admin为用户名，替换RDS的Endpoint为实际RDS的接入点，替换password为实际密码）：
mysqlsh
util.checkForServerUpgrade('admin@db01.cvwawwygiwfi.ap-southeast-1.rds.amazonaws.com:3306',{"password":"1qazxsw2"})
准备好运行命令，如下截图：
执行后返回结果如下截图：
在以上结果中：Errors: 0，这是最好的结果。Warnings: 11 这个信息通常不会导致兼容性问题。
检查结果建议如下：
- 返回Error的，必须解决，调整现有5.7版本的数据库Schema，调整应用代码来解决问题
- 返回Warning的，阅读下提示信息，一般可以不用管，例如MySQL的系统库涉及的一些问题等，对业务运行没有影响
- 返回Notice的，可忽略不用看
由此检查工具即可给出诊断建议，以便于兼容性测试和后续的决策。
七、几种升级方式
MySQL 5.7→8.0的升级方式，与去年的MySQL 5.6→5.7的技术路线相同。当时的材料和技术积累依然可作为参考。
1、选定本次升级的目标版本
可原地升级、可通过快照还原、也可以使用RDS控制台原生的蓝绿升级的路径如下：
- RDS 5.7 → RDS 8.0
- Aurora 5.7 → Aurora 8.0
仅能通过DMS等工具手工搭建两个集群复制的蓝绿升级的路径如下：
- RDS 5.7 → Aurora 5.7
- RDS 5.7 → Aurora 8.0
2、升级须知
- 升级前要确保本AWS账户有能够开技术工单的Support Plan，默认的Basic Support Plan不能开技术工单，不能解决升级问题
- 在升级期间不把多项任务放在一起（升级型、换存储、换实例、更新代码、运行sql script 等），这些工作不要和升级混合在一起进行，以免节外生枝
- 确认RDS设置的备份窗口、维护窗口与升级时间不冲突。如果冲突的话，先关闭这些窗口。
- 在发起蓝绿部署、Cut-over切换、原地升级等重要步骤之前，先打快照。不要等待系统自动快照，而是手工打快照，即可保护数据安全，也可缩短停机时间
3、原地升级
需要停机重启，但操作简单。
方法：直接编辑现有RDS集群，修改版本，然后选择立刻生效。
预期的停机时间可事先测试，即从现有的RDS生产环境生成带有全量数据的快照，然后从快照恢复到新的数据库（名称和Endpoint与生成环境不同）。在新恢复的环境上，做原地升级测试，验证其花费时间，最终确定需要申请多长时间的停机窗口。
以一个20GB的数据库为例。如下截图。
数据分布在多张表内。如下截图。
编辑数据库，选择8.0版本的最新版。请不要选择8.0版本中的老版本，小版本也需要升级到最新才能确保安全。
选择立刻升级。如下截图。
原地升级时候会业务中断，需要申请停机窗口。考虑的因素主要是数据量和机型大小这两个因素对可能花费的时间的影响。
以这个测试数据库为例，multi-deployment部署方式，主从两个节点，机型为m5.2xlarge，20张表每张表1GB数据总计20GB，使用gp3的磁盘，默认IOPS为3000。在这种场景下：
- 16:52分发起升级操作，RDS界面立刻显示为Upgrading升级中
- 16:58分集群重启，此时已经可登录，登录后查看版本显示8.0.34，但RDS界面继续显示Upgrading升级中，且Event中也能看到提示信息
- 17:27分升级完成，RDS界面显示集群状态正常
在RDS界面中可看到Logs & events的信息，点击刷新按钮，可根据时间线看到更新进度。如下截图。
查看事件详情。如下截图。
根据以上记录，在特定集群和特定数据量下，原地升级耗时25分钟，供参考。注：数据量和机型配置和升级时间不是简单倍数关系，数据量大10倍不意味着升级时间多10倍。
4、RDS蓝绿部署方式完成升级
在2022年底MySQL 5.6升级5.7的时候，RDS正式推出了蓝绿部署功能，允许为当前集群创建一个新配置的集群，并在二者之间进行切换。原部署为蓝色，新部署为绿色，所有参数在最终切换为生产时候都与原集群相同。
蓝绿部署在最终切换时候需要约1分钟，也可能需要1-5分钟时间完成。尽管官方文档中说明不丢失数据，但依然建议在蓝绿部署的最终切换期间，建议申请停机窗口，将生产系统设置为只读，暂时不要写入数据，然后完成切换后恢复写入。
（1）创建RDS蓝绿部署开始测试
找到正在运行的数据库，选择操作，选择创建蓝绿部署。如下截图。
选择当前8.0版本中最新的版本。如下截图。
需要注意的是，拉起的蓝绿集群，新的集群的实例规格是可以按照要求选择的，但是其存储是默认的io1类型，分配3000 iops，这样的存储成本是较高的。如下截图。
因此，蓝绿集群并行期间建议尽可能短，以节省成本。在蓝绿升级做了cut-over后，最终的目标机器将依然是按照原RDS的类型，一般是gp3存储默认3000iops。因此升级完成后，不需要额外调整参数。因此确保蓝绿窗口并行期间越短，使用io1磁盘的费用越低。
创建新的蓝绿发布集群，大致需要30分钟。数据量较大的话，可能会更长。
创建蓝绿集群完成。如下截图。
从上边的截图中可以看到，蓝色集群为之前的5.7版本，右侧的绿色集群为新的8.0版本。此时生产系统的入口还是保持的默认的，也就是连接到蓝色集群5.7版本。请不要修改生产系统的数据库入口。
测试新的8.0版本，请使用另外的测试应用系统来发起测试。如下文。
（2）对蓝绿部署新拉起的8.0版进行兼容测试
蓝绿部署的新旧两个集群之间，由RDS服务进行自动的持续数据复制。原有5.7版本的旧RDS正常运行，不影响业务使用。
这里使用脚本模拟测试输入不断插入，然后观察运行结果，可看到新的绿色部署版本为8.0，接收到了蓝色节点发来的数据。
此时可以通过Green部署的Endpoint（开头地址类似prod01-green-xxxxx）连接到数据库，进行兼容性测试。
测试期间注意事项：
- 蓝色节点不要执行DDL SQL，也就是不要修改Schema，不要进行调整表结构、增加列等操作，否则会导致复制失败
- 绿色节点（8.0版本）不要进行写入，否则会导致数据不一致
（3）蓝绿入口切换
业务系统测试通过、确定应用程序对接MySQL 8.0没有问题后，执行切换。在开始切换之前，保持生产环境的业务系统继续连接当前的环境。也就是说，生产环境应用系统的数据库入口Endpoint不用修改，切换后流量会自动指向绿色集群。
选中集群，点击操作下拉框中的Switch over按钮。如下截图。
确认可以操作，并设置切换时候的timeout检测周期。默认为5分钟。当前应用系统的生产环境里边的数据库入口还是默认地址，也就是指向蓝色的，那么如果5分钟内从蓝色5.7版本切换绿色8.0版本失败，就自动回滚，也就是流量自动切回蓝色。
切换进行中。
切换中，原来的生产库会有大约1分钟的中断，因此这也是本文为何开头要建议申请停机窗口，在应用系统上将生产库设置为只读的原因。如下截图，模拟生产库的持续写入，可能看到升级期间会有所中断。因此做最终蓝绿版本切换一定是在停止业务的情况下进行。
切换完毕。如下截图。
切换完毕的环境上可以看到，新的名为prod01的版本是8.0版本，也就说，原来的生产环境的应用代码不需要改变数据库入口，就自动连接到了新的8.0环境。原来的旧的5.7版本的数据库被添加了-old字样，成为了prod01-old1。此外，还会有一个如下截图。
（4）删除蓝绿部署
在RDS清单中，找到蓝绿部署的名称，这个名称是前文步骤创建时候自己指定的名称。然后选择删除。如下截图。
确认删除。如下截图。
再删除蓝绿部署后，确认运行正常后，可以删除名为old的5.7 MySQL。如下截图。
至此蓝绿部署方式升级完成。
5、DMS等工具搭建蓝绿部署集群
在2022年底和2023年初，RDS官方的蓝绿部署功能尚未发布之前，所有的RDS升级都是通过DMS等持续复制工具来完成。因此，对于5.7到8.0版本的升级，这一方式依然适用。
简单步骤如下：
- 创建新的8.0版本集群
- 使用DMS在新旧两个集群自建复制数据，并开启CDC持续复制
- 对8.0版本做兼容测试
- 在切换窗口进行流量倒换，停止源5.7集群写入，并修改生产应用到新的8.0集群
使用DMS等工具搭建蓝绿部署集群，工作量大，停机时间比RDS官方的蓝绿部署方式更长。如果是有特殊功能需求，可使用本方式。因此，二者相比，还是建议使用RDS的蓝绿部署来进行升级。
八、小结
综上所述，从安全性角度考虑，5.7到8.0的升级是必要的，也是势在必行的。同时，RDS MySQL 8.0和Aurora MySQL 8.0也分别提供了新的多AZ集群、写入优化、存储优化、以及Serverless V2版本，也具有较大的性能、可用性、弹性扩展优势，值得升级。
利用本文介绍的兼容性检查工具，可诊断当前数据库与MySQL 8.0版本不兼容的问题。相当一部分用户的应用系统是以增删查改的普通使用场景为主，除一些老系统可能存在UTF编码等问题外，相对很少存在其他兼容性问题，可平滑升级到8.0版本。
此外，对于兼容性问题较多、修改代码难度较大的系统，要先升级到RDS MySQL 5.7.44，然后开启Extended Support，不过会产生额外支持费用；又或者转为Aurora MySQL 5.7，以获得额外半年时间不升级也不产生延长支持的延缓。
因此，建议一步到位升级到8.0版本，以获得最佳的使用效果。最后，PostgreSQL 11的退役和升级的决策方式、决策流程和本文重点描写的MySQL 5.7相似，本文不展开讨论，请参阅相关文档。
九、可用资源和参考资料
保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级前置检查
https://aws.amazon.com/cn/blogs/china/amazon-rds-for-mysql-5-7-to-8-0-pre-check/
保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级方案
https://aws.amazon.com/cn/blogs/china/amazon-rds-for-mysql-5-7-to-8-0-upgrade-solution/
保驾护航 – Amazon RDS for MySQL 5.7 到 8.0 升级指南
https://aws.amazon.com/cn/blogs/china/amazon-rds-for-mysql-5-7-to-8-0-upgrade-guide/
5.7 升级 8.0 的升级检查利器 util.checkForServerUpgrade 原理(1)
https://mp.weixin.qq.com/s/EuR7MSaVMOTnQTMh0_RsZQ
RDS Extended Support 延长支持计划发布
RDS MySQL版本管理
使用蓝绿部署
https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/blue-green-deployments.html
Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support
https://aws.amazon.com/blogs/aws/your-mysql-5-7-and-postgresql-11-databases-will-be-automatically-enrolled-into-amazon-rds-extended-support/
全文完。
最后修改于 2023-11-21