在亚马逊 Aurora MySQL 蓝绿部署切换后实施回滚策略 数据库博客

---

在 Amazon Aurora MySQL 蓝绿部署切换后实施回滚策略

关键要点

本帖讨论了在 Amazon Aurora MySQL 蓝绿部署切换后，如何实施有效的回滚策略。回滚计划对于处理意外问题至关重要，确保您能够快速恢复到稳定状态，避免生产环境中的潜在风险。以下是主要步骤：

准备绿色环境暂存以进行回滚。执行 Aurora MySQL 蓝绿部署切换。删除蓝绿部署，这不会影响数据库环境。将生产环境的逻辑复制配置到回滚环境。如有需要，快速切换到回滚环境。

Amazon Aurora 是亚马逊网络服务AWS提供的一种高性能、全托管的关系型数据库服务，它提供了蓝绿部署功能，使数据库更新更安全、简单和快速。蓝绿部署通过逻辑复制创建一个完全托管的暂存环境，允许您进行生产更改的部署和测试，同时确保当前生产数据库的安全。蓝色环境表示当前处理生产工作负载的数据库，而绿色环境则包含必要的更新或更改。蓝绿部署降低了数据库更新或更改例如主要或次要引擎版本升级和系统更新相关的风险和停机时间。您可以有效地切换暂存环境，使其成为新的生产环境，并无须更改应用程序的端点。

极光加速官网入口

尽管经过仔细的计划和严格的测试，蓝绿部署切换后可能仍会出现无法预见的问题。例如，新的生产环境可能遇到应用程序兼容性问题，这在测试阶段可能没有察觉。同时，由于增加的工作负载或资源需求，应用程序性能可能出现下降，这在测试中可能没有准确模拟。在这种情况下，拥有回滚计划显得至关重要。

在此文中，我们讨论了如何执行蓝绿部署切换及如何在切换后设置和实施回滚策略，专注于 Amazon Aurora MySQL 兼容版。

解决方案概述

成功创建和切换到 Aurora MySQL 蓝绿部署后，绿色环境成为新的生产环境。当前生产环境的名称和端点被分配给新提升的生产环境，您的应用程序不需要任何更改。切换后，旧的生产环境将不再与新提升的生产环境同步。旧生产环境中的数据库集群和数据库实例的名称通过在当前名称后附加 old n 来重命名，其中 n 为数字，此旧环境可用作回滚策略。在此过程中，我们在切换后手动设置从新生产环境到旧环境的逻辑复制，以实现意外问题时的回滚计划。

以下图示说明了 Aurora MySQL 蓝绿部署切换后的回滚策略。

实施该解决方案的高级步骤如下：

准备绿色环境暂存以进行回滚。执行 Aurora MySQL 蓝绿部署切换。删除 Aurora MySQL 蓝绿部署。在此阶段，删除蓝绿部署不会影响您的数据库环境。配置从生产环境到回滚环境的逻辑复制。如果生产环境出现任何问题，切换到回滚环境。

在本帖中，我们以 Aurora MySQL 兼容版2MySQL 57作为蓝色环境，以 Aurora MySQL 兼容版3MySQL 80作为绿色环境。

前提条件

要实施此解决方案，您需要以下组件：

一个 Aurora MySQL 蓝绿部署。有关设置说明，请参见 创建蓝绿部署。Aurora MySQL 绿色集群必须与自定义数据库DB集群参数组相关联。有关 Aurora DB 集群参数组的更多信息，请参见 处理 DB 集群参数组。

限制

以下是与此解决方案相关的限制：

MySQL 不正式支持从运行较高主要版本的源数据库实例到运行较低主要版本的目标数据库实例的复制，因此复制可能会遇到问题或困难有关更多详细信息，请参见 MySQL 版本之间的复制兼容性。由于您希望在过渡到新环境后的短时间内有回滚策略，请确保在此期间不使用仅在新数据库版本中可用的新数据库功能。这可能会导致 MySQL 复制错误并阻止回滚到旧版本的可能性。在 MySQL 复制环境中管理模式更改需要仔细规划。一些模式更改，例如 ALTER TABLE、CREATE TABLE 或 DROP TABLE 语句，可能无法与此回滚解决方案一起使用。

准备绿色环境以进行回滚

在蓝绿部署切换之前，为绿色环境配置回滚：

配置 Aurora MySQL 二进制日志

在 Aurora MySQL 蓝绿部署切换之前，确保绿色环境的二进制日志处于活动状态并捕获二进制日志。这些二进制日志对于持续复制至关重要。默认情况下，Aurora MySQL 禁用二进制日志，除非需要将数据复制出 Aurora 集群。在自定义 DB 集群参数组中，将 binlogformat 参数设置为 ROW 或 MIXED 以启用二进制日志。由于 binlogformat 是静态参数，集群的写入 DB 实例必须重启以使更改生效。因此，建议在蓝绿部署切换之前在绿色环境中启用 binlogformat 参数，以避免切换后的任何重启或停机。有关 MySQL 二进制日志的更多信息，请参见 配置 Aurora MySQL 二进制日志。

要确认绿色 Aurora DB 集群的二进制日志是否处于活动状态，请连接到您的实例并运行以下命令：

sqlmysqlgt show variables like logbin Variablename Value logbin ON

在本帖中，我们将 binlogformat 参数设置为 ROW：

sqlmysqlgt show variables like binlogformat Variablename Value binlogformat ROW

配置 Aurora MySQL 二进制日志保留

在使用逻辑复制作为回滚方法时，确保绿色环境中的二进制日志保持足够长的时间是很重要的。要设置二进制日志保留时间，请使用 mysqlrdssetconfiguration 程序，并指定配置参数 binlog retention hours，以及希望在 DB 集群中保留二进制日志的小时数。在 Aurora MySQL 3x 和 Aurora MySQL 版本 211 及更高版本中，最大值为 90 天，而 binlog retention hours 的默认值为 NULL，表示不保留二进制日志。二进制日志保留期应足以处理生产环境与回滚环境之间的最大复制延迟。这是完成蓝绿切换并在回滚环境中配置复制所需的时间。有关 Aurora MySQL 二进制日志保留的更多信息，请参见 配置二进制日志保留。

在本帖中，我们在绿色环境中将二进制日志保留小时数设置为 24，这应该提供充分的时间来完成蓝绿切换和配置回滚环境的复制。

sqlmysqlgt CALL mysqlrdssetconfiguration(binlog retention hours 24)Query OK 0 rows affected (001 sec)

在更改后验证二进制日志保留：

sqlmysqlgt CALL mysqlrdsshowconfigurationG 1 row name binlog retention hours value 24description binlog retention hours specifies the duration in hours before binary logs are automatically delete1 row in set (000 sec)

执行 Aurora MySQL 蓝绿部署切换

切换涉及将 DB 集群及其相关的 DB 实例从绿色环境提升为新的生产 DB 集群。切换之前，生产流量被导向蓝色当前生产环境中的集群。切换成功后，生产流量将路由到之前的绿色暂存环境中的新提升的 DB 集群。

执行 Aurora MySQL 蓝绿部署切换。有关步骤的信息，请参见 切换蓝绿部署，有关切换最佳实践，请参见 切换最佳实践。完成切换后，您将在 AWS Management Console 中看到“Old Blue”和“New Blue”旁边的数据库。新的蓝色环境就是您新提升的生产环境。

切换后，旧的蓝色 DB 集群仅允许读取操作，直到您重启。

切换后，旧生产环境中的 Aurora MySQL DB 集群和 DB 实例将保留。标准费用适用于这些资源。

切换后，从新的蓝色环境捕获二进制日志文件名和位置。它应显示 binlog 文件名和位置，如以下代码所示：

sqlmysqlgt show master status File Position BinlogDoDB BinlogIgnoreDB ExecutedGtidSet mysqlbinchangelog000007 2638 1 row in set (007 sec)

删除蓝绿部署。注意：在切换之前删除蓝绿部署时，Amazon RDS 可选择性地删除绿色环境中的 DB 集群。删除蓝绿部署不会影响蓝色环境。有关更多信息，请参见 删除蓝绿部署。在您删除蓝绿部署后，新旧生产 DB 集群将处于可用状态，如下图所示。

将旧生产 DB 集群设置为只读模式，以避免任何写操作可能导致来源于新生产环境到旧环境的复制问题。要防止在 DB 集群上进行写操作，请通过将 DB 集群参数组中的 readonly 值从 0 更改为 1 来启用 readonly 数据库模式。由于这是动态参数，修改会立即生效，无需重启。

连接到旧生产 DB 集群并验证应用更改后的 DB 实例模式：

sqlmysqlgt show global variables like readonly Variablename Value readonly ON

注意：删除 Aurora 蓝绿部署后，“蓝色”或“绿色”一词不再相关。对于本帖，我们将“新生产”或“新蓝色”环境称为生产环境，而“旧生产”或“旧蓝色”环境称为回滚环境。

在生产 DB 集群上配置复制用户

在生产数据库中，创建一个复制数据库用户。在本帖中，我们创建一个名为 repluser 的用户：

sqlmysqlgt CREATE USER repluser@ltIPaddressgt IDENTIFIED BY ltpasswordgt

此用户需要 REPLICATION CLIENT 和 REPLICATION SLAVE 权限。将这些权限赋予该用户：

sqlmysqlgt GRANT REPLICATION CLIENT REPLICATION SLAVE ON TO repluser@ltIPaddressgt

从生产到回滚 DB 集群配置二进制日志复制

连接到回滚环境 DB 集群端点并运行 SQL 命令，使用 rdssetexternalmaster 配置手动 MySQL 复制。使用您之前收集的 MySQL binlog 文件名和位置：

sqlmysqlgt call mysqlrdssetexternalmaster (database1instance1xxxxxxxxxxxxxrdsamazonawscom 3306 repluser ltPasswordgt ltBinlog filegt ltBinlog positiongt 0)

通过使用 rdsstartreplication 从回滚环境启动 MySQL 复制过程：

sqlmysqlgt CALL mysqlrdsstartreplication Message Slave running normally 1 row in set (103 sec)

从 Aurora MySQL 版本 3 开始，数据控制语言 (DCL) 语句例如 CREATE USER、GRANT 和 REVOKE将不再通过二进制日志复制。如果您计划在复制进行时运行任何 DCL 语句，则需要在源数据库和目标数据库上运行 DCL 语句。

使用 show slave status 验证 MySQL 复制状态，确保复制过程正常运行且没有错误：

sqlmysqlgt pager egrep SlaveIORunningSlaveSQLRunningErrorPAGER set to egrep SlaveIORunningSlaveSQLRunningError

mysqlgt show slave statusG SlaveIORunning Yes SlaveSQLRunning Yes LastError LastIOError LastSQLError SlaveSQLRunningState LastIOErrorTimestamp LastSQLErrorTimestamp

mysqlgt nopagerPAGER set to stdout

回滚步骤

在从生产环境切换回回滚环境的回滚场景中，按照以下步骤操作：

监控复制延迟，以确保回滚环境可以在没有显著延迟的情况下跟上生产环境。在回滚 DB 集群上使用以下命令检查状态：

sqlmysqlgt SHOW SLAVE STATUSG 1 row MasterLogFile mysqlbinchangelog000010 ReadMasterLogPos 2836 RelayLogFile relaybin000123 RelayLogPos 1569 RelayMasterLogFile mysqlbinchangelog000010 SecondsBehindMaster 5

在找到没有显著复制延迟后，停止生产 DB 上的所有应用程序连接。为防止生产 DB 集群进行写操作，可以通过将 DB 集群参数组中的 readonly 值从 0 更改为 1 来启用 readonly 数据库模式。启用 readonly 数据库模式后，通过在生产环境上运行 SHOW MASTER STATUSG 验证二进制日志位置保持不变。这确认数据库中没有发生额外的数据更改。验证所有二进制日志文件和事件已从生产环境复制到回滚 DB 集群。使用以下命令在回滚 DB 集群上检查状态：

sqlmysqlgt SHOW SLAVE STATUSG 1 row RelayMasterLogFile mysqlbinchangelog000010 ExecMasterLogPos 2836 SecondsBehindMaster 0

验证上面输出中的 SecondsBehindMaster，应该为 0。有关更多信息，请参见 secondsBehindMaster。此外，在生产

• • 2026-01-27 13:38:16
  • 52