切换蓝绿部署 - Amazon Aurora

切换蓝绿部署

切换将绿色环境中的数据库集群(包括其数据库实例)提升为生产数据库集群。在切换之前,生产流量将路由到蓝色环境中的集群。切换后,生产流量将路由到绿色环境中的数据库集群。

切换 蓝绿部署不同于在蓝绿部署中提升 绿色数据库集群。如果您通过从操作菜单中选择提升来手动提升绿色数据库集群,则蓝色环境与绿色环境之间的复制会中断,蓝绿部署将进入无效配置状态。

切换超时

您可以指定 30 秒与 3600 秒(一小时)之间的切换超时时间。如果切换所花的时间超过指定的持续时间,则所有更改都将回滚,并且不会对任一环境进行任何更改。原定设置的超时期间为 300 秒(5 分钟)。

切换防护机制

当您开始切换时,Amazon RDS 会运行一些基本检查,以测试蓝绿环境是否准备好进行切换。这些检查称为切换防护机制。如果环境还没有准备好进行切换,这些切换防护机制可以防止发生切换。因此,它们可以避免比预期更长的停机时间,并防止切换开始时可能导致的蓝色和绿色环境之间的数据丢失。

Amazon RDS 在绿色环境中运行以下防护机制检查:

  • 复制运行状况 - 检查绿色数据库集群复制状态是否为正常运行。绿色数据库集群是蓝色数据库集群的副本。

  • 复制滞后 - 检查绿色数据库集群的副本滞后是否在切换的允许范围内。允许的限制基于指定的超时期间。副本滞后表示绿色数据库集群滞后于其蓝色数据库集群的程度。有关更多信息,请参阅诊断并解决只读副本之间的滞后(针对 Aurora MySQL),以及、监控 Aurora PostgreSQL 复制(针对 Aurora PostgreSQL)

  • 主动写入 - 确保绿色数据库集群上没有主动写入。

Amazon RDS 在蓝色环境中运行以下防护机制检查:

  • 外部复制 – 对于 Aurora PostgreSQL,请确保蓝色环境不是自行管理的逻辑源(发布者)或副本(订阅用户)。如果是,我们建议您删除蓝色环境中所有数据库的自行管理的复制插槽和订阅,继续切换,然后重新创建它们以恢复复制。对于 Aurora MySQL,请确保蓝色数据库不是外部二进制日志副本。如果是,请确保它未在主动复制。

  • 长时间运行的活动写入 - 确保蓝色数据库集群上没有长时间运行的活动写入,因为它们会增加副本滞后。

  • 长时间运行的 DDL 语句 - 确保蓝色数据库集群上没有长时间运行的 DDL 语句,因为它们会增加副本滞后。

  • 不支持的 PostgreSQL 更改 – 对于 Aurora PostgreSQL 数据库集群,请确保在蓝色环境中没有进行 DDL 更改,也没有添加或修改大型对象。有关更多信息,请参阅 蓝绿部署的 PostgreSQL 逻辑复制的限制

    如果 Amazon RDS 检测到不支持的 PostgreSQL 更改,它会将复制状态更改为 Replication degraded,并通知您蓝绿部署无法进行切换。要继续切换,我们建议您删除并重新创建蓝绿部署和所有绿色数据库。为此,请选择操作使用绿色数据库删除

切换操作

当您切换蓝绿部署时,RDS 会执行以下操作:

  1. 运行防护机制检查,以验证蓝色和绿色环境是否已准备好进行切换。

  2. 在两个环境中停止对数据库集群进行新的写入操作。

  3. 在这两个环境中删除与数据库实例的连接,并且不允许新的连接。

  4. 等待复制在绿色环境中赶上进度,以便绿色环境与蓝色环境同步。

  5. 重命名这两个环境中的数据库集群和数据库实例

    RDS 重命名绿色环境中的数据库集群和数据库实例,以匹配蓝色环境中相应的数据库集群和数据库实例。例如,假设蓝色环境中数据库实例的名称为 mydb。还假设绿色环境中相应的数据库实例的名称为 mydb-green-abc123。在切换期间,绿色环境中数据库实例的名称更改为 mydb

    RDS 通过在当前名称后面附加 -oldn(其中 n 是一个数字)来重命名蓝色环境中的数据库集群和数据库实例。例如,假设蓝色环境中数据库实例的名称为 mydb。切换后,数据库实例名称可能为 mydb-old1

    RDS 还重命名绿色环境中的端点,以匹配蓝色环境中的相应端点,以便无需更改应用程序。

  6. 允许在这两种环境中连接到数据库。

  7. 允许在新的生产环境中对数据库集群进行写入操作。

    切换后,先前的生产数据库集群仅允许读取操作,。即使您在数据库集群上禁用了 read_only 参数,在您删除蓝绿部署之前,该参数仍保持只读状态。

您可以使用 Amazon EventBridge 监控切换的状态。有关更多信息,请参阅 蓝绿部署事件

如果在蓝色环境中配置了标签,则这些标签将在切换期间复制到新的生产环境。有关标签的更多信息,请参阅 为 Amazon Aurora 和 Amazon RDS 资源添加标签

如果切换开始后由于任何原因在完成之前停止,则所有更改都将回滚,并且不会对任一环境进行任何更改。

切换最佳实践

在切换之前,我们强烈建议您通过完成以下任务来遵循最佳实践:

  • 在绿色环境中彻底测试资源。确保它们正常高效地运行。

  • 监控相关的 Amazon CloudWatch 指标。有关更多信息,请参阅 在切换之前验证 CloudWatch 指标

  • 确定最佳切换时间。

    在切换期间,两个环境中的数据库都会切断写入操作。确定生产环境中流量最低的时间。长时间运行的事务(例如活动的 DDL)会延长您的切换时间,从而延长生产工作负载的停机时间。

    如果您的数据库集群和数据库实例上有大量连接,请考虑在切换蓝绿部署之前,手动将连接减少到应用程序所需的最低数量。实现此目标的一种方法是创建一个脚本,该脚本监控蓝绿部署的状态,并在检测到状态已更改为 SWITCHOVER_IN_PROGRESS 时开始清理连接。

  • 确保两个环境中的数据库集群和数据库实例均处于 Available 状态。

  • 确保绿色环境中的数据库集群运行状况良好且正在复制。

  • 确保您的网络和客户端配置不会将 DNS 缓存存活时间(TTL)增加到五秒以上,这是 Aurora DNS 区域的默认值。
 否则,应用程序将在切换后继续向蓝色环境发送写入流量。

  • 对于 Aurora PostgreSQL 数据库集群,请执行以下操作:

    • 在切换之前,请查看逻辑复制限制并采取任何必需的操作。有关更多信息,请参阅 蓝绿部署的 PostgreSQL 逻辑复制的限制

    • 运行 ANALYZE 操作以刷新 pg_statistics 表。这样可以降低切换后出现性能问题的风险。

注意

在切换期间,您无法修改切换中包含的任何数据库集群

在切换之前验证 CloudWatch 指标

当您切换蓝绿部署时,我们建议您检查 Amazon CloudWatch 中以下指标的值。

  • DatabaseConnections – 使用此指标估算蓝绿部署上的活动水平,并在切换之前确保该值处于部署的可接受水平。如果开启了 Performance Insights,则 DBLoad 是更准确的指标。

  • ActiveTransactions – 如果在任何数据库实例的数据库参数组中 innodb_monitor_enable 设置为 all,请使用此指标来查看是否存在大量可能阻止切换的活跃事务。

有关这些指标的更多信息,请参阅 Amazon Aurora 的 Amazon CloudWatch 指标

在切换之前监控副本滞后

当您切换蓝绿部署时,请确保绿色数据库上的副本滞后接近于零,以减少停机时间。

  • 对于 Aurora MySQL,使用 AuroraBinlogReplicaLag CloudWatch 指标来确定绿色环境上的当前复制滞后。

  • 对于 Aurora PostgreSQL,请使用以下 SQL 查询:

    SELECT slot_name, confirmed_flush_lsn as flushed, pg_current_wal_lsn(), (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance FROM pg_catalog.pg_replication_slots WHERE slot_type = 'logical'; slot_name | flushed | pg_current_wal_lsn | lsn_distance -----------------+---------------+--------------------+------------ logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8 | 37192

    confirmed_flush_lsn 表示发送到副本的最后一个日志序列号(LSN)。pg_current_wal_lsn 表示数据库现在的位置。如果 lsn_distance 为 0,则表示已捕获副本。

切换蓝绿部署

您可以使用 AWS Management Console、AWS CLI 或 RDS API 切换蓝绿部署。

切换蓝绿部署
  1. 登录 AWS Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

  2. 在导航窗格中,选择 Databases(数据库),然后选择要切换的蓝绿部署。

  3. 对于 Actions(操作),选择 Switch over(切换)。

    将出现 Switch over(切换)页面。

    切换蓝绿部署
  4. Switch over(切换)页面上,查看切换摘要。确保两个环境中的资源都符合您的期望。如果不符合预期,请选择 Cancel(取消)。

  5. 对于超时设置,输入切换的时间限制。

  6. 如果您的集群运行 Aurora PostgreSQL,请查看并确认切换前建议。有关更多信息,请参阅 蓝绿部署的 PostgreSQL 逻辑复制的限制

  7. 选择 Switch over(切换)。

要使用 AWS CLI 切换蓝绿部署,请使用带有以下选项的 switchover-blue-green-deployment 命令:

  • --blue-green-deployment-identifier – 指定蓝绿部署的资源 ID。

  • --switchover-timeout – 指定切换的时间限制,以秒为单位。默认值为 300。

例 切换蓝绿部署

对于 Linux、macOS 或 Unix:

aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier bgd-1234567890abcdef \ --switchover-timeout 600

对于 Windows:

aws rds switchover-blue-green-deployment ^ --blue-green-deployment-identifier bgd-1234567890abcdef ^ --switchover-timeout 600

要使用 Amazon RDS API 切换蓝绿部署,请使用带有以下参数的 SwitchoverBlueGreenDeployment 操作:

  • BlueGreenDeploymentIdentifier – 指定蓝绿部署的资源 ID。

  • SwitchoverTimeout – 指定切换的时间限制,以秒为单位。默认值为 300。

切换后

切换后,将保留先前蓝色环境中的数据库集群和数据库实例。标准成本适用于这些资源。蓝色和绿色环境之间的复制和二进制日志记录会停止。

RDS 通过在当前资源名称后面附加 -oldn(其中 n 是一个数字)来重命名蓝色环境中的数据库集群和数据库实例数据库集群被强制进入只读状态。即使您在数据库集群上禁用了 read_only 参数,在您删除蓝绿部署之前,该参数仍保持只读状态。RDS 会命名绿色环境 -newn 中的数据库集群和数据库实例

如果您删除蓝绿部署资源,RDS 会保留 -oldn-newn 资源。

切换蓝绿部署之后

更新使用者的父节点

切换 Aurora MySQL 蓝绿部署后,如果蓝色数据库集群在切换之前有任何外部副本或二进制日志使用者,则必须在切换后更新其父节点以保持复制连续性。

切换后,之前处于绿色环境中的写入器数据库实例会发出一个事件,其中包含主日志文件名和主日志位置。例如:

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier { "Events": [ ... { "SourceIdentifier": "db-instance-identifier", "SourceType": "db-instance", "Message": "Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 804", "EventCategories": [], "Date": "2023-11-10T01:33:41.911Z", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier" } ] }

首先,请确保使用者或副本已应用来自旧蓝色环境的所有二进制日志。然后,使用提供的二进制日志坐标在使用者上恢复应用程序。例如,如果您在 EC2 上运行 MySQL 副本,则可以使用 CHANGE MASTER TO 命令:

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;