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 常见的四种升级方案，在选择方案之前，您需要结合自己的业务场景判断, 比如按照辅助区域是否有业务流量、读请求访问延迟要求、以及停机窗口时间长短等不同的情况来选择合适的方式，最终顺利的完成全球数据库集群升级。

亚马逊AWS官方博客