以最短的停机时间对 Amazon Aurora MySQL 全球数据库执行次要/主要版本升级

作者： 兰吉尼·梅农, 拉杰什·马特卡, 赵婉晨 |

Amazon Aurora 将商用数据库的性能和可用性与开源数据库的简单性和成本效益相结合。一个 Aurora 数据库集群由一个或多个连接到共享和分布式 Aurora 存储卷的数据库实例组成。

Amazon Aurora 全球数据库专为全球分布式应用程序而设计，允许单个 Aurora 数据库跨越多个亚马逊云科技区域。它可以在不影响数据库性能的情况下复制您的数据，支持在每个区域以低延迟进行快速本地读取，并从区域范围的停机中提供灾难恢复。

执行 Aurora MySQL 全球数据库的引擎主要版本升级的步骤可能包括从全局集群中移除所有辅助区域，将主区域的引擎版本升级到更高版本，然后重新创建辅助区域。在撰写本文时，Aurora MySQL 全球数据库不支持就地进行次要版本升级。在此过程中，全局群集暂时存在，没有任何辅助区域。因此，在完成升级并重新创建辅助区域之前，您无法访问全球功能。

根据集群的作用和重要性，您可能只能承受非常短的停机时间，并且需要控制和预测停机窗口。在这种情况下，您可以部署并排运行的集群副本。然后，您可以在生产集群的副本上执行引擎版本升级（或其他维护），而不会影响原始集群的可用性。您还可以将数据从原始集群复制到副本，直到准备好让新集群接管为止。这种方法通常被称为蓝/绿部署。

在撰写本文时，Aurora 全球数据库不支持 Aurora 蓝/绿色托管部署功能，但您仍然可以构建实现相同概念的自管理解决方案。

在这篇文章中，我们展示了如何使用蓝/绿部署技术在最大限度地减少停机时间的情况下对 Aurora MySQL 全球数据库集群执行引擎版本升级。本文中描述的方法使您能够保持全局集群拓扑结构的完整性，并在整个过程中保留对全球功能的访问权限。尽管本文侧重于版本升级，但您可以使用类似的方法进行其他类型的数据库维护或变更管理。

解决方案概述

在蓝/绿部署技术中，蓝色环境代表当前为生产流量提供服务的数据库。绿色环境是蓝色环境的镜像。

您可以在绿色环境上进行版本更改，而不会影响蓝色环境。同时，生产应用程序在蓝色环境中所做的任何数据更改都会使用 MySQL 二进制日志复制持续复制到绿色环境。在绿色环境升级到新版本并准备接管后，您可以将生产流量从蓝色切换到绿色。切换的持续时间决定了应用程序的停机时间。实际上，切换时间取决于两个主要因素：复制延迟以及您可以多快地将应用程序重新配置为使用绿色而不是蓝色。

或者，您可以通过在切换后向相反方向配置复制来实现回滚功能，本质上是在集群角色相反的情况下创建一个新的蓝/绿设置。但是，必须对此进行仔细测试——MySQL 不正式支持下级二进制日志复制，也不能保证在所有用例中都能正常运行，因此在生产环境中实现此功能之前，必须在特定应用程序中对其进行全面测试。

让我们回顾一下实施该解决方案将要经历的步骤。下图显示了升级和多区域部署过程中的四个关键步骤。

步骤如下：

  1. 使用快速数据库克隆将活动集群（蓝色）复制到使用相同引擎版本的新集群（绿色）。您也可以改用快照或时间点恢复，但是由于采用了浅层副本，克隆速度更快、更具成本效益。
  2. 在绿色集群上执行就地主要/次要版本升级。
  3. 在蓝色和绿色环境之间设置 MySQL 二进制日志复制，以保持绿色与蓝色同步。
  4. 在绿色环境中进行调整，以在实例拓扑和其他配置方面与蓝色环境相匹配。在计划停机时段内，将应用程序从蓝色环境切换到绿色环境。

这些步骤描述了蓝/绿部署过程的机制。您可以对次要版本和主要版本升级使用相同的通用方法，但请记住，蓝/绿技术并不能消除升级测试和验证的需要。特别是重大升级，需要额外的验证步骤，然后才能放心地从蓝色切换到绿色。

先决条件

在开始之前，请查看 Aurora MySQL 主要版本升级路径，确认当前版本的 Amazon Aurora MySQL 兼容版本允许您执行就地主要版本升级。确保在蓝色集群上禁用自动次要版本升级，以防止在您进行蓝/绿部署过程时出现意外版本更改。

该解决方案要求在蓝色环境中启用二进制日志记录。如果蓝色集群已经在启用二进制日志的情况下运行，请确保它使用MIXED或ROW二进制日志格式。

如果您担心二进制日志记录对性能的影响，请查看有关 Aurora 版本 2 中的二进制日志改进以及 Aurora 版本 3 中引入的二进制日志相关创新的其他材料。

启用二进制日志记录需要重新启动，因此您可能需要在低流量期间或计划维护时段内重新启动。

要在蓝色环境中启用二进制日志记录，请完成以下步骤：

  1. 为 Aurora MySQL 集群创建自定义集群级参数组。您将使用它来启用和配置必要的二进制日志设置。如果有的话，也可以重复使用现有的自定义群组。
  2. 打开自定义参数组并将静态参数设置binlog_format为MIXED或ROW。不要使用STATEMENT。有关更多详细信息，请参阅二进制日志记录格式以及基于语句和基于行的复制的优缺点。

  1. 仔细检查sync_binlog innodb_flush_log_at_trx_commit 参数是否都设置为 1。
  2. 重启 Aurora 写入器数据库实例binlog_format以生效。
  3. Aurora 写入器数据库实例重启后，连接到数据库并验证二进制日志配置。您应该能够看到二进制日志文件名和位置，如以下示例所示：
mysql> show global variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.02 sec)

mysql> show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000001 |      154 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.02 sec)

下一步是更改二进制日志保留期。在您完成剩余的设置步骤（克隆蓝色环境、执行升级、设置复制）时，蓝色环境必须保留二进制日志。除非另有配置，否则兼容 Aurora MySQL 会自行删除二进制日志，这可能不会给你足够的时间来完成这些步骤。因此，您应该预先配置保留期限，以避免过早删除二进制日志。

  1. 检查现有配置。值为NULL表示未明确配置二进制日志保留期：
mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                          |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL  | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

Query OK, 0 rows affected (0.03 sec)
  1. 使用rds_set_configuration存储过程更改二进制日志保留期：
mysql> call mysql.rds_set_configuration('binlog retention hours',24);
Query OK, 0 rows affected (0.04 sec)

尽管此示例使用 24 小时二进制日志保留期，但您应选择与您的特定备份和复制要求相一致的保留值。更长的保留期会消耗大量的实例存储空间，并可能影响性能，尤其是写入密集型工作负载。

  1. 验证更改后的二进制日志保留情况：
mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                          |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | 24    | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)
Query OK, 0 rows affected (0.01 sec)

在继续操作之前，请确保您的网络和安全配置允许从绿色到蓝色的复制连接。例如，如果您对绿色使用与蓝色的安全组相同的安全组，请确保该安全组允许来自自身的 MySQL 流量。如果这两个环境使用不同的安全组，请确保允许从绿色环境到蓝色环境的 MySQL 流量。

尽管复制流从蓝色流向绿色，但绿色环境会启动复制连接。这就是为什么您的安全配置必须允许从绿色到蓝色的连接。

现在，您可以创建绿色环境并将其用于版本升级了。

使用蓝/绿部署对 Aurora 全球数据库执行版本升级

在本节中，我们描述了使用蓝/绿方法准备 Aurora MySQL 全球数据库以进行版本升级所涉及的步骤。要最大限度地减少设置复制之前累积的二进制日志，请选择低流量窗口来执行以下操作。

从蓝色环境创建快速数据库克隆

从 Aurora 全球数据库集群的主区域创建快速数据库克隆。对克隆使用相同的虚拟私有云 (VPC) 和子网。用蓝/绿术语来说，您克隆的现有集群是蓝色环境，新创建的克隆是绿色环境，如以下屏幕截图所示。

当克隆（绿色环境）准备就绪时，你可以在其写入器实例的日志和事件选项卡上找到 MySQL 二进制日志文件的名称和位置。记下这些 binlog 坐标，以便稍后用于配置复制。

请记住，在撰写本文时，Aurora MySQL 全球数据库不支持就地次要版本升级。如果您按照此流程执行次要版本升级，请暂时不要向 Aurora 克隆（绿色环境）添加辅助区域。在完成升级和设置复制后，您稍后将添加它们。

此时还有两件事需要注意：

  • 在绿色环境中进行必要的调整，使其在参数、功能和其他配置方面与蓝色环境保持一致。如果您正在执行主要版本升级，并且您的蓝色环境使用自定义数据库参数，请为新的 Aurora MySQL 兼容版本创建参数组，并使用您的自定义设置对其进行预配置（以它们适用于较新的主要版本为限）。
  • 决定是否应在绿色环境中启用二进制日志记录。您将需要它来实现蓝/绿回滚功能（可选），或者如果您已经在蓝色环境中使用二进制日志，例如下游变更数据捕获 (CDC) 与其他服务的集成。

在绿色环境中执行就地版本升级

现在，您可以在绿色环境中使用亚马逊云科技管理控制台或亚马逊云科技命令行接口 (亚马逊云科技CLI) 执行 Aurora MySQL 主要版本就地升级或次要版本升级。

如果升级失败，请检查数据库日志并解决遇到的问题。升级失败不会影响蓝色环境中的原始集群。创建一个新克隆并记下上一步中所述的二进制日志坐标，并在问题修复后重新启动升级。

设置二进制日志复制

成功完成升级后，使用以下步骤在蓝群集和绿色群集之间设置 MySQL 二进制日志复制：

  1. 创建复制数据库用户并在两个环境之间配置 MySQL 复制。对于 Aurora MySQL 数据库，skip_name_resolve数据库集群参数设置为 1 (ON) 且无法修改，因此您必须为主机使用 IP 地址（例如 31.0.0/255.255.0.0）或通配符 (%)，而不是域名。连接到蓝色环境群集终端节点并使用以下代码创建复制用户：
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
  1. 向用户授予REPLICATION CLIENT和REPLICATION SLAVE权限：
mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
  1. 使用程序（在 Aurora MySQL 兼容版本 3 中）或rds_set_external_source程序（在 Aurora MySQL 兼容版本 2 中）连接到绿色环境集群终端节点并配置 MySQL 复制。mysql.rds_set_external_master使用您之前记下的 MySQL 二进制日志文件名和位置坐标（在创建克隆之后）：
mysql> CALL mysql.rds_set_external_source ('aurora-mysql-va.cluster-xxxxxx.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000001', 629, 0);
  1. 使用以下rds_start_replication 过程开始复制：
mysql> CALL mysql.rds_start_replication;
  1. 使用 SHOW REPLICA STATUS 语句验证复制状态，并确保复制过程正常运行，没有任何错误。仔细检查Slave_IO_Running和Slave_SQL_Running字段是否均显示 “是”，如以下示例所示：
mysql> pager egrep "Slave_IO_Running|Slave_SQL_Running|Error"
PAGER set to 'egrep "Slave_IO_Running|Slave_SQL_Running|Error"'

mysql> show REPLICA status\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes
       Last_Error:
       Last_IO_Error:
       Last_SQL_Error:
       Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
       Last_IO_Error_Timestamp:
       Last_SQL_Error_Timestamp:

mysql> nopager
PAGER set to stdout

绿色环境/集群现在配置为二进制日志副本。

  1. 将副本设置为read_only。

尽管您尚未使用绿色环境来传输应用程序流量，但您可以采取其他预防措施来防止用户或应用程序直接将数据更改为绿色（这会中断复制）。您可以通过在绿色环境使用的集群read_only参数组中将参数设置为 1 来实现。该read_only设置是一个动态参数，不需要重启即可生效。当设置为 1 时，该参数可防止普通数据库用户运行数据修改语句，但它不会阻止复制线程所做的更改。

您可以用绿色验证来自任何数据库连接的参数值：

mysql> show global variables like 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON    |
+---------------+-------+

为蓝/绿切换做好准备

成功建立从蓝色到绿色环境的二进制日志复制后，接下来的关键步骤包括对绿色环境进行全面测试，包括应用程序功能、性能基准测试和数据库缓存预热。此外，必须在绿色环境中镜像蓝色集群的拓扑，同时通过比较两个环境之间的性能指标来验证切换的总体准备情况。

对绿色环境进行应用程序测试

此步骤的复杂性取决于您执行的是次要版本升级还是主要版本升级。次要升级通常可以通过有限的测试完成，但您仍应非常仔细地查看发行说明。重大升级几乎总是需要大量的应用程序测试和验证工作。

您可以使用绿色环境本身进行只读应用程序测试，但不应使用绿色环境进行写入测试，因为它会干扰复制。您可以使用单独的非生产环境或绿色环境的 Aurora 克隆进行更全面的测试，将读/写流量作为优秀实践。

尽管绿色环境正在积极复制蓝色环境中的生产更改，但这些更改是通过有限数量的复制线程（甚至是单个线程）来简化的。因此，绿色集群的性能指标无法反映生产工作负载的资源使用情况、吞吐量和并发特征，也不能用于蓝绿环境之间的性能比较。

要进行正确、全面的读/写测试，您可能需要一个带有测试套件、工作负载镜像或其他技术来模拟生产流量的独立环境。

从蓝色环境中捕获性能数据

对于主要版本升级，最好在切换之前对现有（蓝色）环境的性能进行基准测试。如果新数据库版本表现出不同的性能概况，这些性能数据可以在以后用于故障排除和优化数据库性能。有关一般性能疑难解答，请参阅 Amazon Aurora MySQL 数据库性能疑难解答。

我们还建议捕获关键的实例级和集群级的 Amazon CloudWatch 指标，这些指标可在以后用于比较和故障排除。此外，来自 Amazon RDS Performance Insights 的数据可以帮助您确定现有顶级 SQL 语句、顶级等待次数、平均查询运行时间（查询延迟）、每秒调用次数（查询吞吐量）等。考虑将捕获这些数据作为基准工作的一部分。

在绿色环境中重新创建蓝色集群拓扑

此时，您的绿色环境已升级，您正在复制蓝色环境中的所有数据更改，所有这些都不会影响蓝色环境的可用性。现在，您可以向绿色环境添加辅助区域，以匹配蓝色环境的现有拓扑。

确认切换准备就绪

为蓝/绿切换做准备，监控两个环境之间的复制状态和复制延迟。你可以直接使用SHOW SLAVE STATUS或SHOW REPLICA STATUS命令，也可以通过 AurorabinlogReplicaLag CloudWatch 指标观察延迟。该指标跟踪来自SHOW SLAVE STATUS（适用于 Aurora MySQL 兼容版本 2）或SHOW REPLICA STATUS（适用于兼容 Aurora MySQL 的版本 3）中的Seconds_Behind_Master字段。如果您遇到高复制延迟，可能会妨碍您找到合适的切换窗口，请参阅 Amazon Aurora MySQL 复制问题以获取故障排除提示。

复制延迟越低，在切换期间等待复制赶上的时间就越短。延迟 0 秒是理想的。

在生产数据库切换之前，请仔细检查您是否已完成所有先前步骤，以使两个环境在实例拓扑、数据库参数、功能和其他配置方面保持一致。确认绿色环境已做好充分准备和预先配置，可以接管。

如果您需要回滚功能（能够从绿色切换回蓝色），请确认在绿色环境中启用二进制日志记录，保留期为几个小时（如前所述）。如果二进制日志不显示为绿色，就不可能以相反的方向启动复制。

在绿色环境中预热数据库缓存

如果应用程序对数据库性能非常敏感，则可以通过运行热门SELECT查询来预热绿色集群上的数据库缓存（缓冲池）。如果您的应用程序支持读/写分离并且可以容忍复制延迟，则还可以考虑使用绿色环境来处理只读流量，作为预热缓存的一种方式。

执行蓝/绿切换

在继续操作之前，请仔细检查复制是否仍在正常运行且没有错误，以及复制延迟是否等于或接近 0。为获得优秀结果，请在计划的维护时段内执行切换，或在活动较少的时段规划切换窗口。

请记住，切勿同时写入两个环境。复制不会自动覆盖写入冲突或从写入冲突中恢复，手动协调冲突可能很困难或不可能。

停止在蓝色环境中写入流量

如前所述，验证绿色环境是否仍处于只读模式。现在，停止应用程序流量，并确保在蓝色环境中完成所有写入活动。

有几种方法可以阻止应用程序流量，从停止应用程序本身到使用蓝色环境上的read_only参数来禁止应用程序写入，尽管后一种选择可能会导致应用程序遇到查询错误。无论选择哪种方法，最终目标都是在切换期间防止在蓝色环境中写入。

为了获得优秀结果，您可以使用read_only参数或使用安全组规则将蓝色环境与写入流量隔离开来。

在绿色环境中停止复制

在停止复制过程之前，请确保将所有二进制日志事件复制并应用到绿色集群上。文件名和位置必须匹配，如以下示例所示。

除了二进制日志位置外，还要在复制状态输出中查找以下值：

  • slave_io_running — 是的
  • slave_sql_running — 是的
  • seconds_Behind_Master — 0
  • sl@@ ave_sql_running_State — Slave 已读取所有中继日志；正在等待更多更新

如果存在任何复制延迟，请等到复制赶上。发生这种情况之后，你就可以停止复制过程了。

  1. 连接到绿色集群。
  2. 使用以下rds_stop_replication步骤停止复制：
mysql> call mysql.rds_stop_replication;
  1. 使用以下rds_reset_external_source步骤删除复制配置：
mysql> call mysql.rds_reset_external_source;
  1. 如果您想配置反向复制以用于备用途，或者让下游 CDC 集成从蓝色读取二进制日志，请从绿色环境获取二进制日志坐标。这些坐标可用于配置反向蓝/绿复制，或重新定位 CDC 集成：
mysql> show master status;
  1. 将read_only数据库参数更改为 0（或关闭），将绿色环境置于读/写模式。立即应用更改。
  2. 验证绿色时read_only是否设置为 OFF：
mysql> show global variables like 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | OFF   |
+---------------+-------+

此时，无论是蓝色还是绿色，都没有应用程序流量，复制已停止，绿色环境已准备好开始接收流量。

执行应用程序切换

现在，绿色环境已经准备就绪，您可以重新配置应用程序以使用绿色集群终端节点而不是蓝色的集群终端节点。由于您无法重命名作为全局数据库一部分的数据库集群，因此绿色环境无法从蓝色环境中接管 DNS 终端节点。因此，连接重新配置必须在应用层本身进行，或者您可以使用中间层解决方案，例如代理或自管理的自定义 Amazon Route 53 终端节点。

如果使用基于 DNS 的切换解决方案，请确保您的应用程序能够毫不拖延地识别 DNS 更改。有关终端节点连接的优秀实践，请参阅使用 Amazon Aurora MySQL。

执行切换后任务

在本节中，我们将介绍其他主题，例如使用反向复制进行回滚和切换后的备份管理。

使用反向复制实现回滚功能

可以在新环境（以前是绿色）和旧环境（以前是蓝色）之间设置反向复制。但是，请务必注意，MySQL 并非 MySQL 正式支持下级复制，可能并非在所有情况下都起作用——在实施这种方法之前，对您的特定应用程序进行全面测试是绝对必要的。这可以通过在切换过程中捕获的 MySQL 二进制日志文件坐标来完成，此前在蓝色停止应用程序流量并禁用绿色复制。这本质上创建了一个新的蓝/绿设置，但集群角色是相反的。

回滚/反向复制技术有两个主要变体：

  • 复制回旧的蓝色环境-这种方法允许您回滚到以前的集群。尽管 MySQL 官方不支持从较新的主要版本复制到较旧的主要版本，但这样的复制设置是可能的，而且很常见。您可能需要额外的步骤（例如配置更改）来处理版本差异。
  • 向前滚动到旧蓝色环境的克隆 — 使用这种方法，您可以保持原始蓝色环境完好无损，而是复制到该环境的克隆环境中。原始环境可以用作额外的恢复选项，也可以出于其他原因让它继续运行。

下图比较了这些方法。

考虑在新升级的环境（以前为绿色）中运行额外的切换后测试和应用程序运行状况检查，这样，如果您确实需要切换回来，则可以尽快做出决定。

备份注意事项

蓝/绿切换过程不会移动任何特定于集群的资源，例如自动备份。从原始蓝色环境中提取的自动数据库备份将与该环境保持关联，而新环境将生成自己的备份。如果您对两种环境的备份所涵盖的天数有特定要求，但出于成本原因不想让原始集群保持运行，则可以停止集群并删除不再需要的手动快照（手动拍摄或使用 Amazon Backup 计划）。如果您需要在删除原始群集时将原始群集恢复到特定时间点，请使用保留自动备份。删除集群后保留一天以上的自动备份需要付费。手动快照不受集群删除的影响：它们会一直保留，直到您将其删除。如果不再需要快照，请及时删除快照，尤其是在因成本原因删除集群时。有关更多信息，请参阅亚马逊 A urora 定价页面。

清理

当你确定不再需要旧的蓝色环境中的资源时，可以将其删除。但是，如果您尚未准备好删除旧资源但想降低总成本，则可以从蓝色集群中移除辅助区域，然后停止其余区域中的数据库实例。

删除所有蓝色群集资源后，您可能还需要移除与该环境相关的任何其他项目（例如，导出到 CloudWatch Logs 的数据库日志文件）。

摘要

在这篇文章中，我们讨论了使用自管理蓝/绿方法升级 Aurora MySQL 全球数据库次要和主要版本的步骤和优秀实践。该解决方案允许您以受控的方式执行数据库升级以及各种其他维护任务，并将停机时间降至最低。

请在评论部分告诉我们您的反馈。

作者简介

Ranjini Menon 是一名驻伦敦的数据库专业解决方案助理架构师。她拥有关系数据库、ERP 咨询和数据工程方面的经验，并热衷于帮助客户踏上亚马逊云科技云之旅，重点是数据库迁移和现代化。

赵婉晨是亚马逊云科技的高级数据库专家解决方案架构师。Wanchen 专门研究亚马逊 RDS 和 Amazon Aurora，并且是 Amazon DMS 的主题专家。Wanchen 与 ISV 合作伙伴合作，设计和实施数据库迁移和现代化战略，并协助客户在亚马逊云科技云中构建可扩展、安全、高性能和强大的数据库架构。

拉杰什·马特卡尔是首席合作伙伴数据库专家解决方案架构师，此前曾在亚马逊云科技工作。他与亚马逊云科技技术和咨询合作伙伴合作，为数据库项目提供指导和技术援助，帮助他们提高解决方案的价值。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。