使用 IaC 原则自动 blue/green 部署 Amazon Aurora 全球数据库 - AWS 规范指引
Summary先决条件和限制架构工具最佳实践操作说明相关资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用 IaC 原则自动 blue/green 部署 Amazon Aurora 全球数据库

Ishwar Chauthaiwale、ANKIT JAIN 和 Ramu Jagini，Amazon Web Services

Summary

对于在 Amazon Aurora 全球数据库上运行关键工作负载的组织来说，管理数据库更新、迁移或扩展的工作可能极具挑战性。确保在零停机的状况下无缝执行这些操作，对于维持服务可用性并避免用户遭遇中断至关重要。

blue/green 部署策略允许您同时运行两个相同的环境：蓝色（当前环境）和绿色（新环境），从而为这一挑战提供了解决方案。 blue/green 策略使您能够以最小的风险和停机时间实施更改、执行测试和在环境之间切换流量。

此模式可帮助您使用基础设施即代码 (IaC) 原则自动执行 Aurora 全球数据库的 blue/green 部署过程。它使用AWS CloudFormationAWS Lambda、和 Amazon Route 53 来简化 blue/green 部署。为了提高可靠性，它使用全局事务标识符 (GTIDs) 进行复制。与二进制日志（binlog）复制相比，基于 GTID 的复制能在环境间提供更优的数据一致性和失效转移能力。

注意

此模式假设您使用的是 Aurora MySQL 兼容版全局数据库集群。如果您改用 Aurora PostgreSQL-Compatible，请使用与 MySQL 命令对应的 PostgreSQL 命令。

通过遵循此模式中的步骤，您可以：

  • 配置绿色 Aurora 全球数据库：使用 CloudFormation 模板可以创建反映现有蓝色环境的绿色环境。

  • 设置基于 GTID 的复制：您可以配置 GTID 复制以保持蓝色环境和绿色环境同步。

  • 无缝切换流量：完全同步后，可以使用 Route 53 和 Lambda 自动将流量从蓝色环境切换到绿色环境。

  • 完成部署：确认绿色环境已完全作为主数据库运行，然后停止复制并清理所有临时资源。

此模式中的方法具有以下优势：

  • 减少关键数据库更新或迁移期间的停机时间：自动化可确保环境之间的顺畅过渡，最大限度地减少服务中断。

  • 支持快速回滚：如果流量切换到绿色环境后出现问题，可以快速恢复到蓝色环境并保持服务连续性。

  • 增强测试与验证：可以在不影响实时蓝色环境的情况下对绿色环境进行全面测试，从而降低生产环境中出现错误的可能性。

  • 确保数据一致性：基于 GTID 的复制技术可使蓝绿环境保持同步，从而防止迁移期间出现数据丢失或不一致的情况。

  • 保持业务连续性：自动化 blue/green 部署有助于在更新或迁移期间保持服务可用性，从而避免长时间中断和经济损失。

先决条件和限制

先决条件

  • 活跃 AWS 账户的.

  • 源 Aurora MySQL 兼容版全局数据库集群（蓝色环境）。全球数据库提供多区域配置，助力实现高可用性和灾难恢复。有关设置全球数据库集群的说明，请参阅 Aurora 文档。

  • 在源集群上启用了 基于 GTID 的复制。

限制

产品版本

  • Aurora MySQL 兼容版 8.0 或更高版本

架构

使用 GTID 复制技术同步不同区域中的蓝色和绿色环境。

下图说明了以下内容：

  • 全局数据库设置：Aurora 全球数据库集群策略性地部署在两个集群上 AWS 区域。此配置支持地理分布和区域冗余，从而增强了灾难恢复能力。

  • 主区域到辅助区域复制：逻辑复制机制确保从主区域到辅助区域的无缝数据同步。这种复制可保持数据一致性，同时最大限度地减少跨地理距离的延迟。

  • 集群之间基于 GTID 的复制：基于 GTID 的复制技术可在蓝色主集群与绿色主集群之间维持事务一致性与有序数据流，确保数据同步的可靠性。

  • 蓝色主集群到辅助集群复制：逻辑复制可在蓝色主集群与其辅助集群之间建立强大的数据管道。这种复制可实现连续的数据同步与高可用性。

  • Route 53 DNS 配置：Route 53 托管区记录管理所有蓝绿集群数据库端点的 DNS 解析。此配置可提供无缝的端点映射，并在失效转移场景中实现高效的流量路由。

工具

Amazon Web Services

  • Amazon Aurora 是与 MySQL 和 PostgreSQL 兼容的完全托管式的云端关系数据库引擎。

  • CloudFormation帮助您对 AWS 资源进行建模和设置，这样您就可以花更少的时间管理这些资源，而将更多的时间集中在运行的应用程序上 AWS。您可以创建一个描述所需所有 AWS 资源的模板，并 CloudFormation 负责为您配置和配置这些资源。

  • AWS Lambda 是一项计算服务，无需预调配或管理服务器即可运行代码。Lambda 只在需要时运行您的代码，并自动进行扩展，从每天几个请求扩展到每秒数千个请求。 

  • Amazon Route 53 是一种可用性高、可扩展性强的 DNS Web 服务。

最佳实践

我们建议您仔细阅读 AWS 文档，以加深对 Route 53 中的蓝/绿部署策略、基于 GTID 的复制和加权路由策略的理解。这些知识对于有效实施和管理数据库迁移、确保数据一致性、优化流量路由至关重要。通过全面了解这些 AWS 功能和最佳实践，您将能够更好地处理未来的更新，最大限度地减少停机时间并维护弹性和安全的数据库环境。

有关使用此模式 AWS 服务 的指南，请参阅以下 AWS 文档：

操作说明

Task说明所需技能

从蓝色集群创建快照备份。

在 blue/green 部署中，绿色环境代表当前（蓝色）数据库环境的全新、相同版本。在切换生产流量之前，可以使用绿色环境来安全地测试更新、验证更改并确保稳定性。它充当实施数据库变更的临时平台，能最大限度地减少对实时环境的干扰。

要创建绿色环境，请先在 Aurora MySQL 兼容版全局数据库中创建主（蓝色）集群的快照。此快照为创建绿色环境奠定了基础。

要创建快照：

  1. 登录 AWS 管理控制台 并打开亚马逊关系数据库服务 (Amazon RDS) 控制台。

  2. 选择主（蓝色）集群。

  3. 依次选择操作、拍摄快照。

  4. 为快照提供名称（例如 blue-green-demo），然后启动备份过程。

或者，您可以使用 AWS Command Line Interface (AWS CLI) 来创建快照：

aws rds create-db-cluster-snapshot --db-cluster-snapshot-identifier blue-green-demo --db-cluster-identifier ex-global-cluster --region eu-west-1

请确保快照成功完成，然后再进入下一步。

数据库管理员

为您的全局数据库及其资源生成 CloudFormation 模板。

CloudFormation IaC 生成器可帮助您利用现有 AWS 资源生成 CloudFormation 模板。使用此功能为现有 Aurora MySQL 兼容的全局数据库及其相关资源创建 CloudFormation 模板。此模板配置子网组、安全组、参数组和其他设置。

  1. 按照 CloudFormation 文档中的说明导航到该工具并将其连接到您的 AWS 环境。

  2. 选择您的 Aurora 全球数据库和关联资源以生成模板。

数据库管理员

修改绿色环境的 CloudFormation 模板。

自定义 CloudFormation 模板以反映绿色环境的设置。这包括更新资源名称和标识符，确保绿色环境独立于蓝色集群运行。

  1. 更新DBClusterIdentifier 和 DBInstanceIdentifier 属性以表示绿色环境。

  2. 修改其他资源名称（例如子网组和安全组），以避免与现有的蓝色环境发生冲突。

  3. 按照 Aurora 文档中所述，配置正确的参数以在模板中启用基于 GTID 的复制。

  4. 更改SnapshotIdentifier属性以指定 AWS 区域、您的账户 ID 和上一步中的快照名称：

    SnapshotIdentifier: arn:aws:rds:<region>:<account-id>:snapshot:<snapshot-name>
注意

如果您使用 SnapshotIdentifier 属性恢复数据库集群，请避免指定诸如 GlobalClusterIdentifier、MasterUsername 或 MasterUserPassword 之类的属性。

数据库管理员

部署 CloudFormation 堆栈为绿色环境创建资源。

在此步骤中，您将部署自定义 CloudFormation 模板来创建绿色环境的资源。

要部署 CloudFormation 堆栈，请执行以下操作：

  1. 打开 AWS CloudFormation 控制台。

  2. 在右上方依次选择创建堆栈和使用新资源（标准）。

  3. 上传修改后的 CloudFormation 模板或指定模板网址。选择下一步。

  4. 输入堆栈名称（例如 GreenClusterStack），并提供任何必要的参数（例如 GreenClusterIdentifier）。选择下一步。

  5. 根据需要配置其他堆栈选项，然后选中复选框以确认 CloudFormation 可能会创建 AWS Identity and Access Management (IAM) 资源。选择下一步。

  6. 查看堆栈详细信息。

  7. 选择提交。

CloudFormation 启动创建绿色环境资源的过程。此过程可能需要几分钟才能完成。

数据库管理员

验证 CloudFormation 堆栈和资源。

CloudFormation 堆栈部署完成后，您需要验证绿色环境是否已成功创建：

  1. 在 CloudFormation 堆栈的输出部分，检查数据库集群和数据库实例的终端节点以验证设置是否正确。

  2. 打开 Amazon RDS 控制台并确认新的 Aurora 数据库集群（绿色环境）是否可用。

  3. 确保所有关联资源（例如子网和安全组）皆已创建并链接到绿色环境。

验证完成后，您的绿色环境即已准备就绪，可进行后续配置，包括从蓝色环境复制数据。

数据库管理员
Task说明所需技能

验证蓝色集群上的 GTID 设置。

GTIDs 为在蓝色和绿色环境之间复制数据提供了一种高度可靠的方法。基于 GTID 的复制通过为蓝色环境中的每件事务分配唯一标识符，带来一种弹性、简化的方法。与传统的二进制日志复制相比，此方法可确保环境间的数据同步无缝衔接、保持一致，且更易于管理。

在配置复制之前，您需要确保在蓝色集群上正确启用基于 GTID 的复制。此步骤确保在蓝色环境中的每件事务都能被唯一追踪，并可复制到绿色环境中。

要确认 GTID 是否启用：

  1. 在 Amazon RDS 控制台上，查看分配给蓝色集群的参数组。

  2. 验证是否设置了以下参数：

    • gtid-mode = ON

    • enforce_gtid_consistency = ON

这些设置将为蓝色环境中的所有未来事务启用 GTID 跟踪。确认这些设置之后，就可以开始设置复制。

数据库管理员

创建复制用户。

要将数据从蓝色环境复制到绿色环境，需要在蓝色集群上创建专用的复制用户。该用户将负责管理复制流程。

要设置复制用户：

  1. 使用 MySQL 客户端连接到蓝色集群。

  2. 运行以下命令以创建复制用户：

    CREATE USER 'repl_user'@'%' IDENTIFIED BY 'repl_password'; GRANT REPLICATION SLAVE ON . TO 'repl_user'@'%'; FLUSH PRIVILEGES;

此用户现在即拥有在两个环境之间复制数据的必要权限。

数据库管理员

在绿色集群上配置基于 GTID 的复制。

下一步是为基于 GTID 的复制配置绿色集群。此设置可确保绿色环境将持续同步蓝色环境中发生的全部事务。

要配置绿色集群：

  1. 使用 MySQL 客户端连接到绿色集群。

  2. 运行以下命令以配置复制：

    CHANGE MASTER TO MASTER_HOST='blue-cluster-endpoint', MASTER_USER='repl_user', MASTER_PASSWORD='repl_password', MASTER_AUTO_POSITION=1;

    其中：

    • 将 blue-cluster-endpoint 替换为蓝色集群的端点。

    • MASTER_AUTO_POSITION=1 设置会指示 MySQL 使用基于 GTID 的复制。它会自动定位绿色集群以复制蓝色集群的事务，而无需手动跟踪日志和位置。

数据库管理员

开始在绿色集群上复制。

您现在可以启动复制流程。在绿色集群上运行以下命令：

START SLAVE;

这使绿色环境能够开始同步数据，并从蓝色环境接收和应用事务。

数据库管理员

验证复制过程。

要验证绿色环境是否准确地复制了蓝色集群中的数据：

  1. 在绿色集群上运行以下命令以检查复制状态：

    SHOW SLAVE STATUS\G;

  2. 查看输出以验证以下内容：

    • Slave_IO_Running = Yes

    • Slave_SQL_Running = Yes

    • Retrieved_Gtid_Set和的Executed_Gtid_Set值 up-to-date与蓝色群集同步。

    • Last_Error 现场没有复制错误。

如果所有指标都正确，说明基于 GTID 的复制运行平稳，绿色环境已与蓝色环境完全同步。

数据库管理员
Task说明所需技能

配置 Route 53 加权路由策略。

验证完蓝色和绿色环境之间的数据一致性之后，可以将流量从蓝色集群切换至绿色集群。这种过渡应该平稳进行且最大限度地减少停机时间，并确保应用程序数据库的完整性。为满足这些要求，可以使用 Route 53 进行 DNS 路由，使用 Lambda 自动切换流量。此外，完善的回滚方案可确保在出现任何问题时，您能够恢复到蓝色集群。

第一步是在 Route 53 中配置加权路由。加权路由允许您控制蓝色和绿色集群之间的流量分布，并逐步将流量从一个环境转移到另一个环境。

要配置加权路由：

  1. 打开 Route 53 控制台并选择您的托管区。

  2. 为数据库创建两条 DNS 记录 (CNAMEs)：一条记录用于蓝色集群，一条记录用于绿色集群。

  3. 分配初始权重：

    • 为绿色集群设置较低的初始权重（例如 5%），先发送一小部分流量进行测试。

    • 为蓝色集群设置较高的权重（例如 95%），以便保留大部分流量。

    此配置可助力在完全切换之前，先逐步过渡，从而降低风险并支持实时测试。

有关加权路由策略的更多信息，请参阅 Route 53 文档。

AWS DevOps

部署 Lambda 函数来监控复制延迟。

为确保绿色环境与蓝色环境完全同步，部署一个 Lambda 函数来监控集群之间的复制延迟。此函数可检查复制状态，特别是 Seconds_Behind_Master 指标，以确定绿色集群是否已准备好处理所有流量。

以下是您可以使用的 Lambda 函数示例：

import boto3

def check_replication_lag(event, context):
    client = boto3.client('rds')
    response = client.describe_db_instances(DBInstanceIdentifier='green-cluster-instance')
    replication_status = response['DBInstances'][0]['ReadReplicaDBInstanceIdentifiers']
    if replication_status:
        lag = replication_status[0]['ReplicationLag']
        return lag
    return -1

此函数检查复制延迟并返回值。如果延迟为零，说明绿色集群与蓝色集群完全同步。

AWS DevOps

使用 Lambda 自动调整 DNS 权重。

当复制延迟达到零时，即可将所有流量切换到绿色集群。可以使用另一个 Lambda 函数来自动完成此过渡，该函数会调整 Route 53 中的 DNS 权重，将流量 100% 定向到绿色集群。

以下是自动切换流量的 Lambda 函数示例：

import boto3

def switch_traffic(event, context):
    route53 = boto3.client('route53')
    lag = check_replication_lag(event, context)
    if lag == 0:
        response = route53.change_resource_record_sets(
            HostedZoneId='YOUR_HOSTED_ZONE_ID',
            ChangeBatch={
                'Changes': [
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'GreenCluster',
                            'Weight': 100,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'green-cluster-endpoint'}]
                        }
                    },
                    {
                        'Action': 'UPSERT',
                        'ResourceRecordSet': {
                            'Name': 'db.example.com',
                            'Type': 'CNAME',
                            'SetIdentifier': 'BlueCluster',
                            'Weight': 0,
                            'TTL': 60,
                            'ResourceRecords': [{'Value': 'blue-cluster-endpoint'}]
                        }
                    }
                ]
            }
        )
        return response

此功能会检查复制延迟，并在延迟为零时更新 Route 53 DNS 权重，以将流量完全切换到绿色集群。

注意

割接过程中，如果蓝色集群遇到大量写入流量，请考虑在割接期间暂停写入操作。这样可以确保复制及时完成，并防止蓝色集群与绿色集群之间出现数据不一致的情况。

AWS DevOps

验证流量切换。

Lambda 函数调整 DNS 权重后，您应验证所有流量是否都定向到绿色集群以及切换是否成功。

要验证：

  1. 监控 Route 53 DNS 记录，确认流量正被定向到绿色集群。有关更多信息，请参阅 Route 53 文档。

  2. 通过确认用户正在从绿色环境中获得服务来检查应用程序性能。

  3. 验证数据库连接，以确认绿色集群正在处理所有数据库请求。

  4. 监控 Amazon CloudWatch 指标，以了解任何延迟、复制延迟或性能下降的迹象。有关更多信息，请参阅 Aurora 文档。

如果一切运行正常，流量切换即告完成。

AWS DevOps

如果遇到任何问题，请回滚更改。

制定回滚计划至关重要，可防止流量切换后出现任何问题。以下是必要时快速恢复至蓝色集群的方法：

  1. 恢复 Route 53 中的 DNS 权重：使用相同的 Lambda 函数或手动调整 Route 53 DNS 权重，将 100% 的流量引导回蓝色集群。

  2. 监控应用程序性能：立即监控应用程序日志、 CloudWatch 指标和数据库性能，以确认切换回蓝色环境已解决问题。

  3. 识别并解决问题：在尝试再次切换流量之前，调查并解决绿色集群的所有问题。

实施此回滚计划可确保在出现任何意外问题时，将对用户的干扰降至最低。

AWS DevOps
Task说明所需技能

在绿色集群上停止基于 GTID 的复制。

将流量从蓝色环境切换至绿色环境后，应验证过渡是否成功，并确保绿色集群按预期运行。此外，必须停止蓝色和绿色集群之间基于 GTID 的复制，因为绿色环境现在用作主数据库。完成这些任务可确保您的环境安全可靠、运行高效，并为持续运营提供最佳支持。

要停止复制：

  1. 使用 MySQL 客户端连接到绿色集群。

  2. 在绿色集群上运行以下 SQL 命令以停止复制流程：

    STOP SLAVE;

  3. （可选）如果需要，可以重置复制配置以清除所有剩余的复制设置：

    RESET SLAVE ALL;

停止复制后，绿色集群将完全独立，并作为工作负载的主数据库环境运行。

数据库管理员

清理资源。

清理从蓝色集群迁移至绿色集群过程中创建的任何临时或未使用资源，可确保您的环境保持优化、安全且具有成本效益。清理工作包括调整安全设置、进行最终备份以及停用不必要的资源。

要清理资源：

  1. 更新安全组：配置与蓝色和绿色集群关联的安全组，以反映新的主环境（绿色）。若蓝色环境不再需要，请限制对其访问权限，并验证绿色集群的安全设置是否遵循最佳实践。

  2. 对绿色集群进行最终备份：迁移完成后，拍摄绿色集群的最终快照作为备份。如有必要，将来可以使用此快照来恢复环境。

    aws rds create-db-snapshot --db-instance-identifier green-cluster-instance --db-snapshot-identifier green-cluster-final-snapshot

  3. 查看和移除临时资源：查看迁移期间创建的所有临时资源，例如临时安全组、快照或其他配置。删除不再需要的资源，避免不必要的开支。例如，如果不再需要蓝色集群，请将其删除：

    aws rds delete-db-cluster --db-cluster-identifier blue-cluster-identifier --skip-final-snapshot

清理资源有助于维护安全高效的环境，降低成本，并确保仅保留必要的基础设施。

AWS DevOps

相关资源

CloudFormation:

Amazon Aurora：

蓝绿部署策略：

基于 GTID 的复制：

AWS Lambda:

Amazon Route 53：

MySQL 客户端工具：