亚马逊AWS官方博客
Aurora MySQL 2 升级之 Global Database 处理方案
前言
随着社区停止 MySQL 5.7 的支持,Aurora MySQL 2(兼容 MySQL 5.7)的标准支持也将在 2024/10/31 正式停止,并从 2024 年 12月 1 日开始收取扩展支持费用。
为保证数据库的平稳升级,及不同场景的的升级需求差异。我们推出一些列文章,每一篇记录了细分场景的完整过程。
- Aurora MySQL 2 升级方案
- Aurora MySQL 2 升级前置准备
- Aurora MySQL 2 升级预检查-上
- Aurora MySQL 2 升级预检查-下
- Aurora MySQL 2 升级之流量兼容性检查辅助工具
- Aurora MySQL 2 升级之 Global Database 处理方案(本文)
- Aurora MySQL 2 升级之下游 Binlog 消费处理方案 – Canal
- Aurora MySQL 2 升级之下下游 Binlog 消费处理方案 – Flink CDC
本文通过详细的步骤,讲述 Aurora MySQL 2(兼容 MySQL 5.7)全球数据库(Global Database)大版本升级常见的方案。
升级概览
Amazon Aurora Global Database 支持跨多个 AWS 区域部署数据库集群,由一个可写的主区域和最多 5 个只读的辅助区域组成。所有写操作都直接在主区域进行,数据复制到辅助区域通常不到 1 秒的延迟。使用 Amazon Aurora Global Database,您可以通过跨多个 AWS 区域的单个 Aurora 数据库来运行您的全局分布式应用程序,从而实现业务就近读取或者全球容灾目的。
Aurora Global Database 2 升级到 3 的升级过程和 Aurora 数据库集群过程升级大致相同,但升级之前需要注意一些重要的区别。我们建议您将 Aurora Global Database 主数据库集群和辅助数据库集群升级到相同版本,因为仅当主数据库集群和辅助数据库集群具有相同的主要、次要和补丁级别引擎版本时,您才能对 Aurora 全局数据库进行跨区域故障转移。
本文以 Aurora MySQL 2.11.5 升级到 Aurora MySQL 3.05.2 为例来说明升级的过程。Aurora MySQL 2.11.5 版本号中,2 表示主要版本,Aurora MySQL 版本 2 与 MySQL 5.7 兼容,Aurora MySQL 3.05.2 版本号中,3 表示主要版本,Aurora MySQL 版本 3 与 MySQL 8.0 兼容。
Aurora Global Database 升级方案主要有以下几种,对比如下:
升级方案 | 方案优势 | 方案劣势 | 适用场景 | 备注 |
主集群蓝绿升级 | 停机时间短,升级复杂度低 保留 endpoint,对应用透明 |
需要删除辅助集群 | 可以在升级过程中删除辅助集群,并在升级完成后重新添加辅助集群 | 首推方案, 注意部分场景限制 自定义参数组需要手动重启绿环境生效(建议在 switchover 之前) |
手动蓝绿升级 | 停机时间短 | 升级复杂度高,需要通过全量+增量手动创建一套绿环境。并且应用需要切换 endpoint | 要求停机时间短,而且不能删除辅助集群的场景 | 如果数据量大,全量复制时间较长 |
就地升级 | 升级复杂度低,操作简单 | 停机时间长 | 可以接受较长的停机时间 | 成本最低, 对于自定义参数组需要在升级之后重启生效(特别注意 Binlog 消费) |
快照恢复 | 操作简单,新建一套集群,不影响原集群的使用 | 数据不是最新 | 比较适合升级前的应用功能测试 | 支持 5.7 快照还原为 8.0 |
主集群蓝绿升级
蓝绿升级创建一个生产环境的暂存环境,蓝色环境是当前的生产环境,绿色环境是暂存环境,暂存环境使用 binlog 逻辑复制与当前生产环境保持同步。您可以在绿色环境中对 Aurora DB 集群进行更改,而不会影响生产工作负载。例如,您可以在暂存环境中升级主要或次要 DB 引擎版本或更改数据库参数。您可以在绿色环境中彻底测试更改,准备就绪后,您可以切换环境,将绿色环境提升为新的生产环境。切换通常不到一分钟,不会丢失数据,也不需要更改应用程序。如果您在升级过程中指定任何自定义参数组,请确保在升级完成后手动重启集群,这样做会使集群开始使用您的自定义参数设置。
但是蓝绿升级存在如下限制:
- 不支持作为 Aurora global database 一部分的 DB 集群
- 对于 Aurora MySQL,蓝色环境 DB 集群不能是外部 binlog 副本
- 不支持 Amazon RDS Proxy
- 不支持跨区域只读副本
- 不支持使用 AWS Secrets Manager 管理主用户密码
所以对于 Aurora Global Database,如果要使用蓝绿升级,必须先删除辅助集群,蓝绿升级完成后再添加辅助集群。如果应用程序不能接受删除辅助集群,不能使用蓝绿升级的方案。
升级步骤如下:
1. 删除 Aurora global database
下图是典型的 Aurora global database,主集群 database-2,辅助集群 database-2-cluster-1,要升级这个这个集群,首先要把主集群 database-2 和辅助集群 database-2-cluster-1 从 global database 中删除。
![]() |
辅助集群脱离 Global database,该操作完成之后,辅助集群和主集群的数据复制会自动断开,成为一个独立的集群,并且期间不会对主集群造成中断影响,操作方式如下图:
![]() |
![]() |
主集群脱离 Global database,该操作不会导致主集群读写中断,操作方式如下图:
![]() |
![]() |
2. 升级主集群
2.1 创建蓝绿部署
当主集群 database-2 和辅助集群 database-2-cluster-1 均脱离 global database,才能开始创建蓝绿部署。
在为 Aurora MySQL 数据库集群创建蓝绿部署之前,该集群自定义参数组必须开启二进制日志记录(binlog_format),因为从蓝色环境复制到绿色环境需要二进制日志记录,我们建议使用 ROW 格式以降低复制不一致的风险。启用二进制日志记录后,请务必重启数据库集群以使您的更改生效。蓝绿部署要求写入器实例与数据库集群参数组同步,否则创建将失败。
![]() |
创建蓝绿部署
![]() |
给蓝绿部署取个名字 database2-bluegreen,选择 Aurora 3 的目标版本、集群参数组和数据库参数组
![]() |
2.2 查看蓝绿部署
创建完成后的架构如下
![]() |
选中 database2-bluegreen,在 Monitoring 页面 AuroraBinlogReplicaLag 指标中可以看到复制的延迟。
也可以登录绿环境,执行 show slave status,在 Seconds_Behind_Master 列中查看复制延迟。
在 Aurora 3 中,也可以执行 show replica status,在 Seconds_Behind_Source 列中查看复制延迟。
![]() |
2.3 执行蓝绿切换
选中 database2-bluegreen,在 Action 菜单中选择 Switch over
![]() |
选择超时时间,您可以指定 30 秒与 3600 秒(一小时)之间的切换超时时间,如果切换所花的时间超过指定的持续时间,则所有更改都将回滚,并且不会对任一环境进行任何更改。默认设置的超时期间为 300 秒(5 分钟),建议保留默认的 5 分钟,时间太短可能会切换失败。
在切换期间,通常会有一分钟以内的读写中断,建议切换选择在流量最低的时间。另外,长时间运行的事务(例如活动的 DDL)会延长您的切换时间,从而延长生产工作负载的停机时间。
如果您的数据库集群和数据库实例上有大量连接,请考虑在切换蓝绿部署之前,手动将连接减少到应用程序所需的最低数量。实现此目标的一种方法是创建一个脚本,该脚本监控蓝绿部署的状态,并在检测到状态已更改为 SWITCHOVER_IN_PROGRESS
时开始清理连接。
![]() |
2.4 删除蓝绿部署
切换完成之后,绿环境成为新的蓝环境,蓝环境被标注为旧的蓝环境“Old Blue”
![]() |
选中 database2-bluegreen,在 Action 中选择 delete 删除
![]() |
![]() |
删除完成后,database-2 是升级完成后的 Aurora3 数据库,数据库的 endpiont 不会改变,应用程序不用修改。
旧的蓝环境会成为一个独立的数据库集群 database-2-old1
![]() |
2.5 回退方案
如果担心升级后数据库出现异常,此时应用又已经写入数据,可以在蓝绿切换之后,启动应用之前,搭建 Aurora 3 到 Aurora 2 的复制。binlog 的位点可以在蓝绿切换的事件中找到
![]() |
3. 新建辅助集群
升级完成后,需要重新添加辅助集群,辅助集群的版本默认和主集群保持一致。
![]() |
为辅助集群创建自定义的参数组
![]() |
辅助集群添加完成
![]() |
至此,Aurora Global database 数据库已经从 Aurora 2 升级到 Aurora 3。
手动蓝绿升级
对于主集群蓝绿升级方案,最大的问题在于需要先把辅助集群从 Aurora Global database 中删除,对于某些应用,可能不能接受删除辅助集群,但又要求较短的停机时间,可以考虑使用手动蓝绿的方式。所谓手动蓝绿就是自己部署一套绿环境,并建立从蓝环境(生产环境)到绿环境的全量+增加同步,通过切换 endpoint 的方式切换到绿环境完成数据库的升级。
![]() |
第一步:创建 Aurora 3 版本绿环境,绿环境是完整的一套 Aurora Global database,包括主集群和辅助集群,绿环境和蓝环境通过 binlog 建立全量+增量同步,可以是原生的主从同步,也可以是 DMS 等复制工具,具体的步骤参见升级系列博客的其它文章,这里不再赘述。
第二步:等蓝绿环境复制追平后,在业务低峰期停止主区域和辅助区域的应用程序,并把 endpoint 从 Aurora 2 蓝环境切换到 Aurora 3 绿环境,从而完成数据库版本的升级。endpoint 切换可以通过 DNS CName、配置中心或者修改配置文件的方式完成切换。
就地升级
如果您有一个与 MySQL 5.7 兼容的 Aurora Global database,并希望将其升级到与 MySQL 8.0 兼容的 Aurora Global database,您可以通过在集群本身上运行升级过程来实现。这种升级是就地升级,这种技术保留了集群的相同 endpoint 和其他特征,升级相对较快,因为不需要将所有数据复制到新的集群卷。这种稳定性有助于最小化应用程序中的配置更改,它还有助于减少对升级后集群的测试量,因为 DB 实例的数量及其实例类都保持不变。
就地升级机制涉及在操作进行时关闭 Aurora Global database,Aurora 同时升级 global database 中的主集群和所有辅助集群,Aurora 执行干净的关闭,并完成未完成的操作,如事务回滚和撤消清除。所以就地升级会导致应用中断,建议在提升级提前测试,预估停机时间,并在应用维护期间进行升级。
选中 global database ,点击 Modify
![]() |
选择目标数据库版本 Aurora MySQL 3.05.2
![]() |
集群参数组和数据库参数组会使用 Aurora 3 默认的参数,升级完成后需要改成自定义参数组,对于静态参数需要重启使其生效。
![]() |
升级完成后把主集群和辅助集群的参数组改成自定义参数组并重启。至此,Aurora Global database 数据库升级完成。
快照恢复升级
Amazon RDS 可以创建数据库集群的存储卷快照,并备份整个数据库集群而不仅仅是单个数据库。您可以通过从数据库快照还原来创建新的数据库集群,新的集群可以指定新的数据库版本,比如您可以从 Aurora MySQL 2.11.5 快照中恢复过程中指定升级到 Aurora MySQL 3.05.2,从而完成数据库的升级。
因为快照是过去某个时间点的数据,不是最新的数据,在应用不停写的情况下, 这种升级方式会导致数据丢失,恢复时间也比较长,比较适合升级前恢复出一个新版本的数据库,用于应用的测试。
选择 Aurora MySQL 2.11.5 的快照,Action 菜单中选择 restore snapshot
![]() |
指定新的数据库版本为 Aurora MySQL 3.05.2
![]() |
为新的集群选择集群参数组和数据库参数组
![]() |
恢复完成,新的数据库版本 Aurora MySQL 3.05.2
![]() |
恢复后数据库只有一个读写节点,需要为集群增加只读副本,如果是 Aurora Global database,还需要添加辅助集群。
最终, 您将拥有一套新的 Global Database 集群,数据是快照时的全量数据。
总结
本博客总结了 Aurora Global Database 常见的四种升级方案,在选择方案之前,您需要结合自己的业务场景判断, 比如按照辅助区域是否有业务流量、读请求访问延迟要求、以及停机窗口时间长短等不同的情况来选择合适的方式,最终顺利的完成全球数据库集群升级。
参考文档
- Amazon Aurora Global Database
- Amazon Aurora Global Database major version upgrade
- Amazon RDS Blue/Green Deployments