

# 使用 Amazon Aurora 蓝绿部署进行数据库更新
<a name="blue-green-deployments"></a>

蓝绿部署将生产数据库环境复制到单独的同步暂存环境。通过使用 Amazon Aurora 蓝绿部署，您可以在不影响生产环境的情况下对暂存环境中的数据库进行更改。例如，您可以升级主数据库引擎版本或次要数据库引擎版本，或在暂存环境中更改数据库参数。准备就绪后，可以将暂存环境提升为新的生产数据库环境，在此环境中，停机时间通常不到一分钟。

Amazon Aurora 通过在生产环境中*克隆*底层 Aurora 存储卷来创建暂存环境。暂存环境中的集群卷仅存储对该环境所做的增量更改。

**注意**  
目前，Aurora MySQL、Aurora PostgreSQL 和 Aurora Global Database。有关 Amazon RDS 引擎可用性，请参阅《Amazon RDS 用户指南》**中的[使用 Amazon RDS 蓝绿部署进行数据库更新](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)。

**Topics**
+ [

# Amazon Aurora 蓝绿部署概述
](blue-green-deployments-overview.md)
+ [

# 在 Amazon Aurora 中创建蓝绿部署
](blue-green-deployments-creating.md)
+ [

# 查看 Amazon Aurora 中的蓝绿部署
](blue-green-deployments-viewing.md)
+ [

# 切换 Amazon Aurora 中的蓝绿部署
](blue-green-deployments-switching.md)
+ [

# 删除 Amazon Aurora 中的蓝绿部署
](blue-green-deployments-deleting.md)

# Amazon Aurora 蓝绿部署概述
<a name="blue-green-deployments-overview"></a>

通过使用 Amazon Aurora 蓝绿部署，您可以进行数据库更改并测试，然后再在生产环境中实施这些更改。*蓝绿部署* 会创建一个复制生产环境的暂存环境。在蓝绿部署中，*蓝色环境* 是当前的生产环境。*绿色环境* 是暂存环境，与当前生产环境保持同步。

您可以在绿色环境中更改 Aurora 数据库集群，而不会影响生产工作负载。例如，您可以升级主要或次要数据库引擎版本或在暂存环境中更改数据库参数。您可以彻底测试绿色环境中的变化。准备就绪后，您可以*切换*环境，以将绿色环境转换为新的生产环境。切换通常需要不到一分钟，不会丢失数据，也无需更改应用程序。

由于绿色环境是生产环境拓扑的副本，因此数据库集群及其所有数据库实例都将在部署中复制。绿色环境还包括数据库集群使用的功能，例如数据库集群快照、性能详情、增强监控和 Aurora Serverless v2。

**注意**  
Aurora MySQL、Aurora PostgreSQL 和 Aurora Global Database 支持蓝绿部署。有关 Amazon RDS 可用性，请参阅《Amazon RDS 用户指南》**中的 [Amazon RDS 蓝绿部署概述](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)。

**Topics**
+ [

## 区域和版本可用性
](#blue-green-deployments-region-version-availability)
+ [

## 使用 Amazon RDS 蓝绿部署的优势
](#blue-green-deployments-benefits)
+ [

## 蓝绿部署的工作流
](#blue-green-deployments-major-steps)
+ [

# 授权访问 Amazon Aurora 蓝绿部署操作
](blue-green-deployments-authorizing-access.md)
+ [

# Amazon Aurora 蓝绿部署的限制和注意事项
](blue-green-deployments-considerations.md)
+ [

# Amazon Aurora 蓝绿部署最佳实践
](blue-green-deployments-best-practices.md)

## 区域和版本可用性
<a name="blue-green-deployments-region-version-availability"></a>

功能可用性和支持因每个数据库引擎的特定版本以及 AWS 区域而异。有关更多信息，请参阅 [支持蓝绿部署的区域和 Aurora 数据库引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md)。

## 使用 Amazon RDS 蓝绿部署的优势
<a name="blue-green-deployments-benefits"></a>

通过使用 Amazon RDS 蓝绿部署，您可以随时了解最新的安全补丁，提高数据库性能，并在短暂且可预测的停机时间内采用更新的数据库功能。蓝绿部署降低了数据库更新（例如主要或次要引擎版本升级）的风险和减少了停机时间。

蓝绿部署提供以下优势：
+ 轻松创建生产就绪的暂存环境。
+ 自动将数据库更改从生产环境复制到暂存环境。
+ 在不影响生产环境的情况下在安全的暂存环境中测试数据库更改。
+ 通过数据库补丁和系统更新保持最新状态。
+ 实施和测试更新的数据库功能。
+ 在不更改应用程序的情况下，将您的暂存环境切换为新的生产环境。
+ 使用内置切换防护机制安全切换。
+ 消除切换期间的数据丢失。
+ 快速切换，通常不到一分钟，具体取决于您的工作负载。

## 蓝绿部署的工作流
<a name="blue-green-deployments-major-steps"></a>

使用蓝绿部署进行 Aurora 数据库集群更新时，请完成以下主要步骤。

1. 确定需要更新的生产数据库集群。

   下图显示了一个生产数据库集群的示例。  
![\[蓝绿部署中的生产（蓝色）Aurora 数据库集群\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png)

1. 创建蓝绿部署。有关说明，请参阅[在 Amazon Aurora 中创建蓝绿部署](blue-green-deployments-creating.md)。

   下图显示了步骤 1 中生产环境的蓝绿部署示例。在创建蓝绿部署时，RDS 会复制 Aurora 数据库集群的完整拓扑和配置以创建绿色环境。复制的数据库集群和数据库实例的名称附加了 `-green-random-characters`。映像中的暂存环境包含数据库集群（auroradb-green-**abc123**）。它还包含数据库集群中的三个数据库实例（auroradb-instance1-green-**abc123**、auroradb-instance2-green-**abc123** 和 auroradb-instance3-green-**abc123**）。  
![\[Amazon Aurora 的蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png)

   创建蓝绿部署时，可以为绿色环境中的数据库集群指定更高的数据库引擎版本和不同的数据库集群参数组。您还可以为数据库集群中的数据库实例指定不同的数据库参数组。

   RDS 还配置从蓝色环境中的主数据库实例到绿色环境中的主数据库实例的复制。
**重要**  
对于 Aurora MySQL 版本 3，在创建蓝绿部署后，绿色环境中的数据库集群默认情况下不支持写入操作。但是，这一点不适用于具有 `CONNECTION_ADMIN` 权限的用户，包括 Aurora 主用户。拥有此权限的用户可以覆盖 `read_only` 行为。有关更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。

1. 对暂存环境进行更改。

   例如，您可以在绿色环境中更改一个或多个数据库实例使用的数据库实例类。

   有关修改数据库集群的信息，请参阅[修改 Amazon Aurora 数据库集群](Aurora.Modifying.md)。

1. 测试您的暂存环境。

   在测试期间，建议您将绿色环境中的数据库保持为只读状态。在绿色环境中启用写入操作需谨慎，因为它们可能导致复制冲突。它们还可能导致切换后生产数据库中出现意外数据。要对 Aurora MySQL 启用写入操作，请将 `read_only` 参数设置为 `0`，然后重启数据库实例。对于 Aurora PostgreSQL，请在会话级别将 `default_transaction_read_only` 参数设置为 `off`。

1. 准备就绪后，切换以将暂存环境转换为新的生产环境。有关说明，请参阅[切换 Amazon Aurora 中的蓝绿部署](blue-green-deployments-switching.md)。

   切换会导致停机。停机时间通常不到一分钟，但根据您的工作负载，停机时间可能会更长。

   下图显示了切换后的数据库集群。  
![\[切换 Amazon Aurora 蓝绿部署后的数据库集群和数据库实例\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png)

   切换后，绿色环境中的 Aurora 数据库集群将成为新的生产数据库集群。当前生产环境中的名称和端点分配给新转换的生产环境，无需更改您的应用程序。因此，您的生产流量现在流向新的生产环境。蓝色环境中的数据库集群和数据库实例通过向当前名称附加 `-oldn`（其中 `n` 是一个数字）来重命名。例如，假设蓝色环境中数据库实例的名称为 `auroradb-instance-1`。切换后，数据库实例名称可能为 `auroradb-instance-1-old1`。

   在本例的映像中，切换期间会发生以下变化：
   + 绿色环境数据库集群 `auroradb-green-abc123` 成为名为 `auroradb` 的生产数据库集群。
   + 名为 `auroradb-instance1-green-abc123` 的绿色环境数据库实例成为生产数据库实例 `auroradb-instance1`。
   + 名为 `auroradb-instance2-green-abc123` 的绿色环境数据库实例成为生产数据库实例 `auroradb-instance2`。
   + 名为 `auroradb-instance3-green-abc123` 的绿色环境数据库实例成为生产数据库实例 `auroradb-instance3`。
   + 名为 `auroradb` 的蓝色环境数据库集群成为 `auroradb-old1`。
   + 名为 `auroradb-instance1` 的蓝色环境数据库实例成为 `auroradb-instance1-old1`。
   + 名为 `auroradb-instance2` 的蓝色环境数据库实例成为 `auroradb-instance2-old1`。
   + 名为 `auroradb-instance3` 的蓝色环境数据库实例成为 `auroradb-instance3-old1`。

1. 如果您不再需要蓝绿部署，可将其删除。有关说明，请参阅[删除 Amazon Aurora 中的蓝绿部署](blue-green-deployments-deleting.md)。

   切换后，之前的生产环境不会被删除，因此如有必要，您可以将其用于回归测试。

# 授权访问 Amazon Aurora 蓝绿部署操作
<a name="blue-green-deployments-authorizing-access"></a>

用户必须具有所需的权限才能执行与蓝绿部署相关的操作。您可以创建 IAM policy，以便为用户和角色授予权限以对所需的指定资源执行特定的 API 操作。然后，可以将这些策略附加到需要这些权限的 IAM 权限集或角色。有关更多信息，请参阅 [Amazon Aurora 的 Identity and Access Management](UsingWithRDS.IAM.md)。

创建蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource` 
+ `rds:CreateDBCluster` 
+ `rds:CreateDBInstance` 
+ `rds:CreateDBClusterEndpoint` 

切换蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBCluster` 
+ `rds:PromoteReadReplicaDBCluster` 

删除蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBCluster` 
+ `rds:DeleteDBInstance` 
+ `rds:DeleteDBClusterEndpoint` 

Aurora 代表您预调配和修改暂存环境中的资源。这些资源包括使用内部定义命名约定的数据库实例。因此，附加的 IAM 策略不能包含部分资源名称模式，例如 `my-db-prefix-*`。仅支持通配符（\$1）。通常，我们建议使用资源标签和其它支持的属性来控制对这些资源的访问权限，而不是使用通配符。有关更多信息，请参阅 [Actions, resources, and condition keys for Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html)。

## Aurora Global Database 蓝绿部署的其它权限
<a name="blue-green-deployments-authorization-global"></a>

 为 Aurora Global Database 集群创建蓝绿部署时，除了上面列出的权限外，用户还需要以下权限才能执行管理全局集群拓扑的操作。

创建蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:CreateGlobalCluster`

切换蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`

删除蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:DeleteGlobalCluster`

# Amazon Aurora 蓝绿部署的限制和注意事项
<a name="blue-green-deployments-considerations"></a>

要在 Amazon RDS 中进行蓝绿部署，需要仔细考虑复制插槽、资源管理、实例大小以及对数据库性能的潜在影响等因素。以下各节提供的指导有助于您优化部署策略，以确保尽可能地减少停机时间、实现无缝过渡并有效地管理数据库环境。

**Topics**
+ [

## 蓝绿部署的限制
](#blue-green-deployments-limitations)
+ [

## 蓝绿部署的 Aurora Global Database 限制
](#blue-green-deployments-limitations-agd)
+ [

## 蓝绿部署注意事项
](#blue-green-deployments-consider)

## 蓝绿部署的限制
<a name="blue-green-deployments-limitations"></a>

以下限制适用于蓝绿部署。

**Topics**
+ [

### 蓝绿部署的一般限制
](#blue-green-deployments-limitations-general)
+ [

### Aurora MySQL 蓝绿部署的限制
](#blue-green-deployments-limitations-mysql)
+ [

### 采用逻辑复制的 Aurora PostgreSQL 蓝绿部署的
](#blue-green-deployments-limitations-postgres-logical)

### 蓝绿部署的一般限制
<a name="blue-green-deployments-limitations-general"></a>

以下一般限制适用于蓝绿部署：
+ 您无法停止和启动属于蓝绿部署一部分的集群。
+ 蓝绿部署不支持使用 AWS Secrets Manager 管理主用户密码。
+ 如果您尝试对蓝色数据库集群强制执行回溯，则蓝绿部署会中断并阻止切换。
+ 在切换期间，蓝色和绿色环境无法与 Amazon Redshift 进行零 ETL 集成。您必须先删除集成，接着切换，然后重新创建集成。
+ 创建蓝绿部署时，必须在绿色环境中禁用事件调度器（`event_scheduler` 参数）。这样可以防止在绿色环境中生成事件并导致不一致。
+ 在蓝色数据库集群上配置的自动扩缩策略不会复制到绿色环境。无论它们最初是在蓝色还是绿色环境中设置的，切换之后都必须重新配置。
+ 您无法将未加密的数据库集群更改为加密的数据库集群。此外，无法将加密的数据库集群更改为未加密的数据库集群。
+ 无法将蓝色数据库集群更改为比其相应的绿色数据库集群更高的引擎版本。
+ 蓝色环境和绿色环境中的资源必须位于同一个 AWS 账户中。
+ 以下功能不支持蓝绿部署：
  + Amazon RDS 代理
  + 跨区域只读副本
  + Aurora Serverless v1 数据库集群
  + CloudFormation

### Aurora MySQL 蓝绿部署的限制
<a name="blue-green-deployments-limitations-mysql"></a>

以下限制适用于 Aurora MySQL 蓝绿部署：
+ 源数据库集群不能包含任何名为 `tmp` 的数据库。具有此名称的数据库将不会复制到绿色环境中。
+ 蓝色数据库集群不能是外部二进制日志副本。
+ 如果源数据库集群启用了回溯功能，则创建的绿色数据库集群不支持回溯功能。这是因为回溯功能不适用于二进制日志（binlog）复制，而二进制日志复制是蓝绿部署所必需的。有关更多信息，请参阅 [回溯 Aurora 数据库集群](AuroraMySQL.Managing.Backtrack.md)。
+ 蓝绿部署不支持适用于 MySQL 的 AWS JDBC 驱动程序。有关更多信息，请参阅 GitHub 上的 [Known Limitations](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)。

### 采用逻辑复制的 Aurora PostgreSQL 蓝绿部署的
<a name="blue-green-deployments-limitations-postgres-logical"></a>

以下限制适用于使用逻辑复制的 Aurora PostgreSQL 蓝绿。
+ [Unlogged](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED)（未记录的）表不会复制到绿色环境，除非在蓝色数据库集群上将 `rds.logically_replicate_unlogged_tables` 参数设置为 `1`。在创建蓝绿部署后不要修改此参数值，以免未记录的表上可能出现复制错误。
+ 蓝色数据库集群不能是逻辑源（发布者）或副本（订阅者）。
+ 如果将蓝色数据库集群配置为外部数据包装器（FDW）扩展的外部服务器，则必须使用集群端点名称而不是 IP 地址。这会让配置在切换后仍能正常运行。
+ 在蓝绿部署中，每个数据库都需要一个逻辑复制插槽。随着数据库数量增长，资源开销会增加，并可能导致复制滞后，尤其是在数据库集群没有充分扩展的情况下。影响取决于数据库工作负载和连接数等因素。要缓解这种情况，可以考虑纵向扩展数据库实例类，或减少源集群上的数据库数量。
+ 适用于 Aurora PostgreSQL 的 Babelfish 仅版本 15.7 及更高的 15 版本，以及 16.3 及更高的 16 版本支持蓝绿部署。
+ 如果要在 Aurora 副本中捕获执行计划，则必须在调用 `apg_plan_mgmt.create_replica_plan_capture` 函数时提供蓝色数据库集群端点。这样可以确保计划捕获在切换后继续进行。有关更多信息，请参阅 [在副本中捕获 Aurora PostgreSQL 执行计划](AuroraPostgreSQL.QPM.Plancapturereplicas.md)。
+ 绿色环境中的逻辑复制 [apply process](https://www.postgresql.org/docs/current/logical-replication-architecture.html) 是单线程的。如果蓝色环境生成大量写入流量，则绿色环境可能无法跟上。这可能会导致复制滞后或失败，特别是对于产生持续高写入吞吐量的工作负载。确保彻底测试工作负载。对于需要主要版本升级和处理大量写入工作负载的场景，可以考虑使用其它方法，例如使用 [AWS Database Migration Service（AWS DMS）](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html)或[自行管理的逻辑复制](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html)。
+ 在执行 Aurora 的蓝绿部署期间，不支持在分区表上创建新分区。创建新分区涉及数据定义语言（DDL）操作（例如 `CREATE TABLE`），这些操作不会从蓝色环境复制到绿色环境。但是，现有的分区表及其数据将复制到绿色环境。
+ 以下限制适用于 PostgreSQL 扩展：
  + 创建蓝绿部署时，必须在蓝色环境中禁用 `pg_partman` 扩展。该扩展将执行 `CREATE TABLE` 等 DDL 操作，这会中断从蓝色环境到绿色环境的逻辑复制。
  + 创建蓝绿部署后，`pg_cron` 扩展必须在所有绿色数据库上保持禁用状态。该扩展具有以超级用户身份运行并绕过绿色环境只读设置的后台工作进程，这可能会导致复制冲突。
  + 在所有绿色数据库上，`apg_plan_mgmt` 扩展必须将 `apg_plan_mgmt.capture_plan_baselines` 参数设置为 `off`，以免在蓝色环境中捕获相同的计划时发生主键冲突。有关更多信息，请参阅 [Aurora PostgreSQL 查询计划管理概览](AuroraPostgreSQL.Optimize.overview.md)。
  + 创建蓝绿部署时，必须在蓝色环境中禁用 `pglogical` 和 `pgactive` 扩展。将绿色环境切换为新的生产环境后，您可以重新启用这些扩展。此外，蓝色数据库不能是外部实例的逻辑订阅者。
  + 如果您使用的是 `pgAudit` 扩展，则它必须保留在蓝色和绿色数据库实例的自定义数据库参数组上的共享库（`shared_preload_libraries`）中。有关更多信息，请参阅 [设置 pgAudit 扩展](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)。

#### 蓝绿部署的特定于逻辑复制的限制
<a name="blue-green-deployments-limitations-postgres"></a>

PostgreSQL 有某些与逻辑复制相关的限制，这会导致创建 Aurora PostgreSQL 数据库集群的蓝绿部署存在限制。

下表描述了适用于 Aurora PostgreSQL 的蓝绿部署的逻辑复制限制。有关更多信息，请参阅 PostgreSQL 逻辑复制文档中的[限制](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。


| 限制 | 说明 | 
| --- | --- | 
| 数据定义语言（DDL）语句，（例如 CREATE TABLE 和 CREATE SCHEMA）不会从蓝色环境复制到绿色环境。 |  如果 Aurora 在蓝色环境中检测到 DDL 更改，则您的绿色数据库将进入**复制已降级**状态。必须删除蓝绿部署和所有绿色数据库，然后重新创建。  | 
| 数据控制语言（DCL）语句（例如 GRANT 和 REVOKE）不会从蓝色环境复制到绿色环境。 |  如果 Aurora 检测到有人试图在蓝色环境中执行 DCL 语句，您将看到一条警告消息。由于这是蓝绿部署过程的限制，因此没有可用于更改此行为的配置或 API。  | 
| 对序列对象执行的 NEXTVAL 操作在蓝色环境和绿色环境之间不同步。 |  在切换期间，Aurora 会增加绿色环境中的序列值，以匹配蓝色环境中的那些序列值。如果您有成千上万的序列，这可能会延迟切换。  | 
| 蓝色环境中的大型对象不会复制到绿色环境中。这既包括现有的大型对象，也包括在蓝绿部署过程中任何新创建或修改的大型对象。 |  如果 Aurora 检测到在蓝色环境中创建或修改了存储在 `pg_largeobject` 系统表中的大型对象，则您的绿色数据库将进入**复制已降级**状态。必须删除蓝绿部署和所有绿色数据库，然后重新创建。  | 
|  刷新实体化视图会导致复制中断。  |  在蓝色环境中刷新实体化视图，会中断向绿色环境的复制。请避免在蓝色环境中刷新实体化视图。切换后，您可以使用 [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 命令手动刷新实体化视图，也可以按计划进行刷新。  | 
|  不允许对没有主键的表执行 UPDATE 和 DELETE 操作。  |  在创建蓝绿部署之前，请确保所有表都有主键或使用 `REPLICA IDENTITY FULL`。但是，仅当主键或唯一键不存在时才使用 `REPLICA IDENTITY FULL`，因为它会影响复制性能。有关更多信息，请参阅 [PostgreSQL 文档](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。  | 

## 蓝绿部署的 Aurora Global Database 限制
<a name="blue-green-deployments-limitations-agd"></a>

除了上述常规限制和引擎特定的限制外，Aurora Global Database 的蓝绿部署还存在以下限制：
+ 所有操作都必须从与 Global Database 的写入器集群相同的区域启动。
+ 执行全局切换或全局失效转移将导致活动的蓝绿部署失效。需要从新的主要区域中删除并重新创建蓝绿部署。
+ 对于 Aurora PostgreSQL，如果您在生产环境中启用了全局写入转发并创建了蓝绿部署，则在绿色集群上禁用写入转发。只有在蓝绿切换后，当绿色环境变为新的生产环境时，才能在绿色环境中启用写入转发。切换后，写入转发在 `-old1` 集群上处于禁用状态。
+ 在创建蓝绿部署后修改全球数据库的拓扑将导致活动的蓝绿部署失效。必须从新的主要区域中删除并重新创建蓝绿部署。
+ 自动快照按最初在旧的蓝色环境中配置的备份保留天数保留。来自旧的蓝色集群的自动快照不会复制到绿色。
+ 在蓝绿切换期间支持全局失效转移，但在蓝绿切换期间不支持全局切换。
+ 确保所有辅助区域中都存在绿色环境的数据库集群和数据库参数组（名称相同）。如果任何区域中的参数组不可用，则使用这些区域中的默认参数组。
+ 在蓝绿部署切换期间，避免在任何全球数据库成员上使用 RDS 代理。

## 蓝绿部署注意事项
<a name="blue-green-deployments-consider"></a>

Amazon RDS 使用每种资源的 `DbiResourceId` 和 `DbClusterResourceId` 跟踪蓝绿部署中的资源。此资源 ID 是资源的 AWS 区域唯一的不可变标识符。

*资源* ID 与数据库*集群*** ID 是分开的。每一个都列在 RDS 控制台的数据库配置中。

当您切换蓝绿部署时，资源的名称（集群 ID）会发生变化，但每个资源都保持相同的资源 ID。例如，在蓝色环境中，数据库集群标识符可能已经为 `mycluster`。切换后，同一个数据库集群可能重命名为 `mycluster-old1`。但是，数据库集群的资源 ID 在切换期间不会更改。因此，当将绿色资源切换为新的生产资源时，它们的资源 ID 与之前生产中的蓝色资源 ID 不匹配。

切换蓝绿部署后，请考虑将资源 ID 更新为新转换的生产资源的 ID，以获得与生产资源一起使用的集成功能和服务。具体而言，请考虑以下更新：
+ 如果您使用 RDS API 和资源 ID 执行筛选，请在切换后调整筛选中使用的资源 ID。
+ 如果您使用 CloudTrail 来审计资源，请调整 CloudTrail 的使用者，以便在切换后跟踪新的资源 ID。有关更多信息，请参阅 [监控 AWS CloudTrail 中的 Amazon Aurora API 调用](logging-using-cloudtrail.md)。
+ 如果您将数据库活动流用于蓝色环境中的资源，请调整您的应用程序以在切换后监视新流的数据库事件。有关更多信息，请参阅 [支持数据库活动流的区域和 Aurora 数据库引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md)。
+ 如果您使用性能详情API，请在切换后调整 API 调用中的资源 ID。有关更多信息，请参阅 [在 Amazon Aurora 上使用性能详情监控数据库负载](USER_PerfInsights.md)。

  您可以在切换后监控同名数据库，但它不包含切换之前的数据。
+ 如果您在 IAM 策略中使用资源 ID，请确保在必要时添加新转换的资源的资源 ID。有关更多信息，请参阅 [Amazon Aurora 的 Identity and Access Management](UsingWithRDS.IAM.md)。
+ 如果您有与数据库集群关联的 IAM 角色，请务必在切换后重新关联它们。附加的角色不会自动复制到绿色环境。
+ 如果您使用 [IAM 数据库身份验证](UsingWithRDS.IAMDBAuth.md)对数据库集群进行身份验证，请确保用于数据库访问的 IAM 策略同时包含在策略的 `Resource` 元素下方列出的蓝色和绿色数据库。这是在切换后连接到绿色数据库所必需的。有关更多信息，请参阅 [创建和使用适用于 IAM 数据库访问的 IAM 策略](UsingWithRDS.IAMDBAuth.IAMPolicy.md)。
+ 如果您想为属于蓝绿部署的数据库集群还原手动数据库集群快照，请确保通过检查快照拍摄时间来还原正确的数据库集群快照。有关更多信息，请参阅 [从数据库集群快照还原](aurora-restore-snapshot.md)。
+ 切换后，AWS Database Migration Service（AWS DMS）复制任务无法恢复，因为蓝色环境中的检查点在绿色环境中无效。您必须使用新的检查点重新创建 DMS 任务后才能继续复制。
+ Amazon Aurora 通过在蓝色环境中*克隆*底层 Aurora 存储卷来创建绿色环境。绿色集群卷仅存储对绿色环境所做的增量更改。如果您删除蓝色环境中的数据库集群，则绿色环境中底层 Aurora 存储卷的大小增长到完全大小。有关更多信息，请参阅 [克隆 Amazon Aurora 数据库集群卷](Aurora.Managing.Clone.md)。
+ 当您在蓝绿部署的绿色环境中向数据库集群添加数据库实例时，当您切换时，新的数据库实例不会替换蓝色环境中的数据库实例。但是，新的数据库实例保留在数据库集群中，并成为新的生产环境中的数据库实例。
+ 在蓝绿部署的绿色环境中删除数据库集群中的数据库实例时，您无法创建新的数据库实例来替换蓝绿部署中的该实例。

  如果您创建一个与已删除的数据库实例具有相同名称和相同 ARN 的新数据库实例，则它具有不同的 `DbiResourceId`，因此它不属于绿色环境。

  如果您在绿色环境中删除数据库集群中的数据库实例，则会导致以下行为：
  + 如果蓝色环境中存在同名的数据库实例，则不会将其切换到绿色环境中的数据库实例。不会通过将 `-oldn` 附加到数据库实例名称来重命名此数据库实例。
  + 切换后，任何指向蓝色环境中数据库实例的应用程序都将继续使用相同的数据库实例。
+ 如果您使用资源标签进行访问控制或操作管理，则需明白，在切换之前，蓝色和绿色环境之间的标签更改不会同步。创建蓝绿部署时，蓝色环境中的标签将被复制到绿色环境中。创建后，您对任一环境所做的所有标签修改都不会自动同步。在切换期间，蓝色环境标签会替换绿色环境中的所有标签。在创建蓝绿部署之前，将所有必要的标签应用于蓝色环境，或者在切换后将所需的标签重新应用于新的生产环境。有关标签的更多信息，请参阅[为 Amazon Aurora 和Amazon RDS 资源添加标签](USER_Tagging.md)。

# Amazon Aurora 蓝绿部署最佳实践
<a name="blue-green-deployments-best-practices"></a>

以下是蓝绿部署的最佳实践。

**Topics**
+ [

## 蓝绿部署的一般最佳实践
](#blue-green-deployments-best-practices-general)
+ [

## Aurora MySQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-mysql)
+ [

## Aurora PostgreSQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-postgres)
+ [

## Aurora Global Database 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-agd)

## 蓝绿部署的一般最佳实践
<a name="blue-green-deployments-best-practices-general"></a>

在创建蓝绿部署时，请考虑以下一般最佳实践。
+ 切换之前，在绿色环境中全面测试 Aurora 数据库集群。
+ 使绿色环境中的数据库保持只读。建议您在绿色环境中谨慎启用写入操作，因为它们可能导致复制冲突。它们还可能导致切换后生产数据库中出现意外数据。
+ 如果您使用蓝绿部署来实现架构更改，则仅进行与复制兼容的更改。

  例如，您可以在表末尾添加新列，而无需中断从蓝色部署到绿色部署的复制。但是，模式更改（例如重命名列或重命名表）会中断向绿色部署的复制。

  有关与复制兼容的更改的更多信息，请参阅 MySQL 文档中的[在源和副本上使用不同的表定义进行复制](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html)以及 PostgreSQL 逻辑复制文档中的[限制](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。
+ 为两个环境中的所有连接使用集群端点、读取器端点或自定义端点。请勿使用带有静态或排除列表的实例端点或自定义端点。
+ 切换蓝绿部署时，请遵循切换最佳实践。有关更多信息，请参阅 [切换最佳实践](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices)。

## Aurora MySQL 蓝绿部署最佳实践
<a name="blue-green-deployments-best-practices-mysql"></a>

从 Aurora MySQL 数据库集群创建蓝绿部署时，请考虑以下最佳实践。
+ 如果绿色环境出现副本滞后，请考虑以下事项：
  + 如果不需要保留二进制日志，请将其禁用，或者在复制赶上进度之前暂时将其禁用。为此，将 `binlog_format` 数据库集群参数重新设置为 `0`，然后重启绿色写入器数据库实例。
  + 在绿色数据库参数组中临时将 `innodb_flush_log_at_trx_commit` 参数设置为 `0`。当复制赶上进度之后，请在切换之前恢复为默认值 `1`。如果使用临时参数值时发生意外关闭或崩溃，请重建绿色环境以避免未检测到的数据损坏。有关更多信息，请参阅[配置刷新日志缓冲区的频率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。

## Aurora PostgreSQL 蓝绿部署最佳实践
<a name="blue-green-deployments-best-practices-postgres"></a>

从 Aurora PostgreSQL 数据库集群创建蓝绿部署时，请考虑以下的最佳实践。
+ 监控 Aurora PostgreSQL 逻辑复制直写缓存，并在必要时对缓存缓冲区进行调整。有关更多信息，请参阅 [监控 Aurora PostgreSQL 逻辑复制直写缓存](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache)。
+ 在蓝色环境中增加 `logical_decoding_work_mem` 数据库参数的值。这样做可以减少磁盘上的解码次数，改为使用内存。有关更多信息，请参阅 [调整工作内存以进行逻辑解码](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)。
  + 您可以使用 `ReplicationSlotDiskUsage` CloudWatch 指标监控写入磁盘的事务溢出量。该指标提供对复制槽的磁盘使用情况的见解，有助于确定事务数据何时超过内存容量并存储在磁盘上。您可以使用 `FreeableMemory` CloudWatch 指标监控可用内存。有关更多信息，请参阅 [Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
  + 在 Aurora PostgreSQL 版本 14 及更高版本中，您可以使用 `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` 系统视图监控逻辑溢出文件的大小。
+ 创建蓝绿部署之前，请将所有 PostgreSQL 扩展更新到最新版本。有关更多信息，请参阅 [升级 PostgreSQL 扩展](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)。
+ 如果您使用的是 `aws_s3` 扩展，请在创建绿色环境之后，通过 IAM 角色赋予绿色数据库集群访问 Amazon S3 的权限。这允许导入和导出命令在切换后继续运行。有关说明，请参阅[设置 Amazon S3 存储桶的访问权限](postgresql-s3-export-access-bucket.md)。
+ 如果您为绿色环境指定更高的引擎版本，请对所有数据库运行 `ANALYZE` 操作来刷新 `pg_statistic` 表。在主要版本升级期间不会传输优化程序统计数据，因此您必须重新生成所有统计数据，来避免出现性能问题。有关主要版本升级期间的其他最佳实践，请参阅[执行主要版本升级](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)。
+ 如果在源中使用触发器来操作数据，请避免将触发器配置为 `ENABLE REPLICA` 或 `ENABLE ALWAYS`。否则，复制系统会传播更改并执行触发器，从而导致重复。
+ 长时间运行的事务可能会导致严重的副本延迟。要减少副本延迟，可考虑执行下列操作：
  + 减少长期运行的事务和子事务，这些事务和子事务可能会延迟到绿色环境赶上蓝色环境之后再运行。
  + 减少蓝色环境上的批量操作，直到绿色环境赶上蓝色环境之后再运行。
  + 在创建蓝绿部署之前，对事务繁忙的表启动手动真空冻结操作。有关说明，请参阅[执行手动 vacuum 冻结](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html)。
  + 在 PostgreSQL 12 及更高版本中，请对大型表或繁忙表禁用 `index_cleanup` 参数，以提高蓝色数据库的常规维护效率。有关更多信息，请参阅[尽快对表执行 vacuum 操作](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)。
**注意**  
在执行 vacuum 操作期间定期跳过索引清理可能会导致索引膨胀，从而降低扫描性能。最佳实践是仅在使用蓝绿部署时使用此方法。部署完成后，建议恢复定期的索引维护和清理。
  + 如果蓝色和绿色数据库实例的大小不足以应付工作负载，则可能会出现副本延迟。确保您的数据库实例未达到该实例类型的资源限制。有关更多信息，请参阅 [使用 Amazon CloudWatch 指标分析 Aurora PostgreSQL 的资源使用情况](AuroraPostgreSQL_AnayzeResourceUsage.md)。
+ 复制缓慢会导致发送方和接收方经常重启，从而延迟同步。要确保它们保持活动状态，请在蓝色环境中将 `wal_sender_timeout` 参数设置为 `0`，在绿色环境中将 `wal_receiver_timeout` 参数设置为 `0`，从而禁用超时。
+ 检查 UPDATE 和 DELETE 语句的性能，并评估在 WHERE 子句中使用的列上创建索引能否优化这些查询。在绿色环境中重播操作时，这可以提高性能。有关更多信息，请参阅。[检查谓词筛选条件是否存在生成等待的查询](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters)
+ 如果您使用的是触发器，请确保它们不会影响名称以“rds”开头的 `pg_catalog.pg_publication`、`pg_catalog.pg_subscription` 和 `pg_catalog.pg_replication_slots` 对象的创建、更新及删除。
+ 如果在源数据库集群上启用了 Babelfish，则绿色环境的目标数据库集群参数组中以下参数的设置必须与源数据库集群参数组中的设置相同：
  + rds.babelfish\$1status
  + babelfishpg\$1tds.tds\$1default\$1numeric\$1precision
  + babelfishpg\$1tds.tds\$1default\$1numeric\$1scale
  + babelfishpg\$1tsql.default\$1locale
  + babelfishpg\$1tsql.migration\$1mode
  + babelfishpg\$1tsql.server\$1collation\$1name

  有关这些参数的更多信息，请参阅 [Babelfish 的数据库集群参数组设置](babelfish-configuration.md)。

## Aurora Global Database 蓝绿部署最佳实践
<a name="blue-green-deployments-best-practices-agd"></a>

除了上面列出的常规和特定于引擎的最佳实践外，还可考虑以下适用于 Aurora Global Database 的最佳实践。
+ 监控以下 CloudWatch 指标，以确定您的生产环境中活动较少的时段：
  + `DatabaseConnections`
  + `ActiveTransactions`

  将蓝绿切换安排在计划的维护时段或活动较少的时段。
+ 蓝绿切换持续时间因工作负载和辅助区域的数量而异。当您启动蓝绿切换时，服务会等待副本滞后达到零之后，才会继续操作。我们建议在启动切换之前检查副本滞后。
+ 如果您打算在绿色环境中使用的数据库参数或数据库集群参数组与默认数据库参数或数据库集群参数组不同，请在启动蓝绿部署之前，在所有辅助区域中创建具有相同名称的所需参数组。

# 在 Amazon Aurora 中创建蓝绿部署
<a name="blue-green-deployments-creating"></a>

RDS 将蓝色环境的拓扑和功能复制到暂存区域。如果蓝色数据库实例具有只读副本，它们将被复制为绿色实例的副本。所有绿色副本分配得到的存储与绿色主实例一致，而其他存储参数则继承自蓝色副本。

创建蓝绿部署时，您需要指定要在部署中复制的数据库集群。您选择的数据库集群是生产数据库集群，它将成为蓝色环境中的数据库集群。RDS 将蓝色环境的拓扑及其配置的功能复制到暂存区域。数据库集群复制到绿色环境，RDS 配置从蓝色环境中的数据库集群到绿色环境中的数据库集群的复制。RDS 还复制数据库集群中的所有数据库实例。

**Topics**
+ [

## 准备进行蓝绿部署
](#blue-green-deployments-creating-preparing)
+ [

## 创建蓝绿部署时指定更改
](#blue-green-deployments-creating-changes)
+ [

## 创建蓝绿部署
](#blue-green-deployments-creating-create)
+ [

## 创建蓝绿部署的设置
](#create-blue-green-settings)

## 准备进行蓝绿部署
<a name="blue-green-deployments-creating-preparing"></a>

在创建蓝绿部署之前，必须执行某些步骤，具体取决于您的 Aurora 数据库集群运行的引擎。

**Topics**
+ [

### 准备 Aurora MySQL 数据库集群以进行蓝绿部署
](#blue-green-deployments-creating-preparing-mysql)
+ [

### 准备 Aurora PostgreSQL 数据库集群以进行蓝绿部署
](#blue-green-deployments-creating-preparing-postgres)
+ [

### 准备 Aurora Global Database 数据库集群以进行蓝绿部署
](#blue-green-deployments-creating-preparing-agd)

### 准备 Aurora MySQL 数据库集群以进行蓝绿部署
<a name="blue-green-deployments-creating-preparing-mysql"></a>

在为 Aurora MySQL 数据库集群创建蓝绿部署之前，该集群必须与开启[二进制日志记录](USER_LogAccess.MySQL.BinaryFormat.md)（`binlog_format`）的自定义数据库集群参数组相关联。从蓝色环境复制到绿色环境需要二进制日志记录。尽管任何二进制日志格式都有效，但我们建议使用 `ROW` 以降低复制不一致的风险。有关创建自定义数据库集群参数组和设置参数的信息，请参阅[Amazon Aurora 数据库集群的数据库集群参数组](USER_WorkingWithDBClusterParamGroups.md)。

**注意**  
启用二进制日志记录会增加集群的写入磁盘 I/O 操作数。您可以使用 `VolumeWriteIOPs` CloudWatch 指标监控 IOPS 使用情况。

启用二进制日志记录后，请务必重启数据库集群以使您的更改生效。蓝绿部署*要求*写入器实例与数据库集群参数组同步，否则创建将失败。有关更多信息，请参阅 [重启 Aurora 集群内的数据库实例](aurora-reboot-db-instance.md)。

此外，建议将二进制日志保留期更改为 `NULL` 以外的其他值，以防止二进制日志文件被清除。有关更多信息，请参阅 [设置和显示二进制日志配置](mysql-stored-proc-configuring.md)。

### 准备 Aurora PostgreSQL 数据库集群以进行蓝绿部署
<a name="blue-green-deployments-creating-preparing-postgres"></a>

在为 Aurora PostgreSQL 数据库集群创建蓝绿部署之前，请务必执行以下操作：
+ 将集群与启用逻辑复制（`rds.logical_replication`）的自定义数据库集群参数组相关联。从蓝色环境复制到绿色环境需要逻辑复制。

  启用逻辑复制时，还需要调整某些集群参数，例如 `max_replication_slots`、`max_logical_replication_workers` 和 `max_worker_processes`。有关启用逻辑复制和调整这些参数的说明，请参阅[为 Aurora PostgreSQL 数据库集群设置逻辑复制](AuroraPostgreSQL.Replication.Logical.Configure.md)。

  此外，请确保 `synchronous_commit` 参数设置为 `on`。

  配置所需参数后，重启数据库集群以使您的更改生效。蓝绿部署*要求*写入器实例与数据库集群参数组同步，否则创建将失败。有关更多信息，请参阅 [重启 Aurora 集群内的数据库实例](aurora-reboot-db-instance.md)。
+ 确认您的数据库集群运行的 Aurora PostgreSQL 版本与蓝绿部署兼容。有关兼容版本列表，请参阅 [Aurora PostgreSQL 的蓝绿部署](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.apg)。
+ 确保数据库集群中的所有表都有主键。PostgreSQL 逻辑复制不允许对没有主键的表执行 UPDATE 或 DELETE 操作。

### 准备 Aurora Global Database 数据库集群以进行蓝绿部署
<a name="blue-green-deployments-creating-preparing-agd"></a>

在为 Aurora Global Database 数据库集群创建蓝绿部署之前，请注意以下几点：
+ 所有操作都必须从与 Global Database 的写入器集群相同的区域启动。
+ 参数组配置：
  + 绿色环境要么使用您指定的新参数组，要么使用与蓝色集群相同的参数组（默认）。
  + 自定义参数组将复制到绿色环境。
  + 如果辅助区域中不存在指定的参数组，则该辅助区域中的默认参数组将用于绿色环境。

## 创建蓝绿部署时指定更改
<a name="blue-green-deployments-creating-changes"></a>

创建蓝绿部署时，可以在绿色环境中对数据库集群进行以下更改：

部署后，您可以在绿色环境中对数据库集群及其数据库实例进行其他修改。例如，您可以指定更高的引擎版本或不同的参数组。

有关修改数据库集群的信息，请参阅[修改 Amazon Aurora 数据库集群](Aurora.Modifying.md)。

**Topics**
+ [

### 指定更高的引擎版本
](#blue-green-deployments-engine-version)
+ [

### 指定其它数据库参数组
](#blue-green-deployments-parameters)

### 指定更高的引擎版本
<a name="blue-green-deployments-engine-version"></a>

如果要测试数据库引擎升级，可以指定更高的引擎版本。切换后，数据库将升级到您指定的主要或次要数据库引擎版本。

### 指定其它数据库参数组
<a name="blue-green-deployments-parameters"></a>

指定与数据库集群使用的数据库集群参数组不同的数据库集群参数组。您可以测试参数更改如何影响绿色环境中的数据库集群，或者在升级时为新的主要数据库引擎版本指定参数组。

如果您指定不同的数据库集群参数组，则指定的参数组将与绿色环境中的数据库集群相关联。如果您未指定其他数据库集群参数组，则绿色环境中的数据库集群将和与蓝色数据库集群相同的参数组关联。

## 创建蓝绿部署
<a name="blue-green-deployments-creating-create"></a>

您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 创建蓝绿部署。

### 控制台
<a name="blue-green-deployments-creating-console"></a>

**创建蓝绿部署**

1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。

1. 在导航窗格中，选择 **Databases**（数据库），然后选择要复制到绿色环境的数据库集群。

1. 依次选择**操作**和**创建蓝绿部署**。

   将出现**创建蓝绿部署**页面。  
![\[创建蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-create-aurora.png)

1. 查看蓝色数据库标识符。确保它们与您在蓝色环境中预期的数据库实例相匹配。如果不符合预期，请选择 **Cancel**（取消）。

1. 对于**蓝绿部署名称**，输入蓝绿部署的名称。

1. 在剩余部分中，指定绿色环境的设置。有关每项设置的信息，请参阅[创建蓝绿部署的设置](#create-blue-green-settings)。

   部署后，可以在绿色环境中对数据库进行其他修改。

1. 选择**创建**。

### AWS CLI
<a name="blue-green-deployments-creating-cli"></a>

要使用 AWS CLI 创建蓝绿部署，请使用 [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html) 命令。有关所有可用选项的信息，请参阅[创建蓝绿部署的设置](#create-blue-green-settings)。

**Example**  
对于 Linux、macOS 或 Unix：  

```
aws rds create-blue-green-deployment \
    --blue-green-deployment-name aurora-blue-green-deployment \
    --source arn:aws:rds:us-east-2:123456789012:cluster:auroradb \
    --target-engine-version 8.0 \
    --target-db-cluster-parameter-group-name mydbclusterparametergroup
```
对于：Windows  

```
aws rds create-blue-green-deployment ^
    --blue-green-deployment-name aurora-blue-green-deployment ^
    --source arn:aws:rds:us-east-2:123456789012:cluster:auroradb ^
    --target-engine-version 8.0 ^
    --target-db-cluster-parameter-group-name mydbclusterparametergroup
```

### RDS API
<a name="blue-green-deployments-creating-api"></a>

要使用 Amazon RDS API 创建蓝绿部署，请使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html) 操作。有关各选项的信息，请参阅 [创建蓝绿部署的设置](#create-blue-green-settings)。

## 创建蓝绿部署的设置
<a name="create-blue-green-settings"></a>

下表说明创建蓝绿部署时可供您选择的设置。有关 AWS CLI 选项的更多信息，请参阅 [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html)。有关 RDS API 参数的更多信息，请参阅 [CreateBlueGreenDeployment](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html)。


| 控制台设置 | 设置说明 | CLI 选项和 RDS API 参数 | 
| --- | --- | --- | 
|  **蓝绿部署标识符**  |  蓝绿部署的名称。  |  **CLI 选项：** `--blue-green-deployment-name` **API 参数：**  `BlueGreenDeploymentName`  | 
| 蓝色数据库标识符 |  要复制到绿色环境的集群的标识符。使用 CLI 或 API 时，请指定集群的 Amazon 资源名称（ARN）。  |  **CLI 选项：** `--source` **API 参数：** `Source`  | 
|  绿色数据库的数据库集群参数组  | 与绿色环境中的数据库相关联的参数组。 |  **CLI 选项：**  `--target-db-cluster-parameter-group-name` **API 参数：**  `TargetDBClusterParameterGroupName`  | 
|  **绿色数据库的引擎版本**  |  将绿色环境中的集群升级到指定的数据库引擎版本。 如果您选择使用逻辑复制的 Aurora PostgreSQL 数据库集群，请回顾并确认逻辑复制的限制。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。  |  **CLI 选项：** `--target-engine-version` **RDS API 参数：** `TargetEngineVersion`  | 

# 查看 Amazon Aurora 中的蓝绿部署
<a name="blue-green-deployments-viewing"></a>

您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 查看有关蓝绿部署的详细信息。

您还可以查看和订阅事件，以了解有关蓝绿部署的信息。有关更多信息，请参阅 [蓝绿部署事件](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)。

## 控制台
<a name="blue-green-deployments-viewing-console"></a>

**查看有关蓝绿部署的详细信息**

1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。

1. 在导航窗格中，选择 **Databases**（数据库），然后在列表中找到蓝绿部署。  
![\[数据库列表中的蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-db-list-aurora.png)

   蓝绿部署的 **Role**（角色）值为 **Blue/Green Deployment**（蓝绿部署）。

1. 选择要查看的蓝绿部署的名称以显示其详细信息。

   每个选项卡都有一个用于蓝色部署的部分和一个用于绿色部署的部分。例如，在**配置**选项卡上，如果在绿色环境中升级数据库引擎版本，则蓝色环境和绿色环境中的数据库引擎版本可能不同。

   下图显示**连接和安全**选项卡的示例：  
![\[蓝绿部署详细信息\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-details-aurora.png)

   **连接和安全**选项卡还包括一个名为**复制**的部分，其中显示了复制的当前状态以及蓝色和绿色环境之间的副本滞后。如果复制状态为 `Replicating`，则表示蓝绿部署复制成功。

   对于使用逻辑复制的 Aurora PostgreSQL 蓝绿，如果您在蓝色环境中进行了不受支持的 DDL 或大型对象更改，则复制状态会变成 `Replication degraded`。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

   下图显示**配置**选项卡的示例：  
![\[蓝绿部署配置详细信息\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-config-aurora.png)

   下图显示**状态**选项卡的示例：  
![\[蓝绿部署状态\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-status-aurora.png)

## AWS CLI
<a name="blue-green-deployments-viewing-cli"></a>

要使用 AWS CLI 查看有关蓝绿部署的详细信息，请使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令。

**Example 通过筛选蓝绿部署的名称来查看有关蓝绿部署的详细信息**  
当您使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令时，可以按 `--blue-green-deployment-name` 进行筛选。  
以下示例显示名为 `my-blue-green-deployment` 的蓝绿部署的详细信息。  

```
aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=my-blue-green-deployment
```

**Example 通过指定蓝绿部署的标识符查看有关蓝绿部署的详细信息**  
使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令时，您可以指定 `--blue-green-deployment-identifier` 选项。  
以下示例显示带有标识符 `bgd-1234567890abcdef` 的蓝绿部署的详细信息。  

```
aws rds describe-blue-green-deployments \
  --blue-green-deployment-identifier bgd-1234567890abcdef
```

## RDS API
<a name="blue-green-deployments-viewing-api"></a>

要使用 Amazon RDS API 查看有关蓝绿部署的详细信息，请使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html) 操作并指定 `BlueGreenDeploymentIdentifier`。

# 切换 Amazon Aurora 中的蓝绿部署
<a name="blue-green-deployments-switching"></a>

*切换*将绿色环境中的数据库集群（包括其数据库实例）转换为生产数据库集群。在切换之前，生产流量将路由到蓝色环境中的集群。切换后，生产流量将路由到绿色环境中的数据库集群。

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

**Topics**
+ [

## 切换超时
](#blue-green-deployments-switching-timeout)
+ [

## 切换防护机制
](#blue-green-deployments-switching-guardrails)
+ [

## 切换操作
](#blue-green-deployments-switching-actions)
+ [

## 切换最佳实践
](#blue-green-deployments-switching-best-practices)
+ [

## 在切换之前验证 CloudWatch 指标
](#blue-green-deployments-switching-over-cloudwatch)
+ [

## 在切换之前监控副本滞后
](#blue-green-deployments-monitor-replica-lag)
+ [

## 切换蓝绿部署
](#blue-green-deployments-switching-over)
+ [

## 切换后
](#blue-green-deployments-switching-after)

## 切换超时
<a name="blue-green-deployments-switching-timeout"></a>

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

## 切换防护机制
<a name="blue-green-deployments-switching-guardrails"></a>

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

Amazon RDS 在绿色环境中运行以下防护机制检查：
+ **复制运行状况** - 检查绿色数据库集群复制状态是否为正常运行。绿色数据库集群是蓝色数据库集群的副本。
+ **复制滞后** - 检查绿色数据库集群的副本滞后是否在切换的允许范围内。允许的限制基于指定的超时期间。副本滞后表示绿色数据库集群滞后于其蓝色数据库集群的程度。有关更多信息，请参阅 [在切换之前监控副本滞后](#blue-green-deployments-monitor-replica-lag)。
+ **主动写入** - 确保绿色数据库集群上没有主动写入。

Amazon RDS 在蓝色环境中运行以下防护机制检查：
+ **外部复制** – 对于 Aurora PostgreSQL，请确保蓝色环境不是自行管理的逻辑源（发布者）或副本（订阅用户）。如果是，建议您删除蓝色环境中所有数据库的自行管理的复制插槽和订阅，继续切换，然后重新创建它们以恢复复制。对于 Aurora MySQL，请确保蓝色数据库不是外部二进制日志副本。如果是，请确保它未在主动复制。
+ **长时间运行的活动写入** - 确保蓝色数据库集群上没有长时间运行的活动写入，因为它们会增加副本滞后。
+ **长时间运行的 DDL 语句** - 确保蓝色数据库集群上没有长时间运行的 DDL 语句，因为它们会增加副本滞后。
+ **不支持的 PostgreSQL 更改** – 对于使用逻辑复制的 Aurora PostgreSQL，确保在蓝色环境中没有进行 DDL 更改，也没有添加或修改大型对象。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

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

## 切换操作
<a name="blue-green-deployments-switching-actions"></a>

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

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

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

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

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

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

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

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

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

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

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

   切换之后，先前的生产数据库集群仅允许读取操作。即使您对数据库集群启用写入，它仍为只读的，直到您删除蓝绿部署。

您可以使用 Amazon EventBridge 监控切换的状态。有关更多信息，请参阅 [蓝绿部署事件](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)。

在切换期间，蓝色环境中的标签会替换绿色环境中相应资源上的所有标签。在此过程中，您直接添加到绿色环境资源的所有标签都将被覆盖。有关标签的更多信息，请参阅[为 Amazon Aurora 和Amazon RDS 资源添加标签](USER_Tagging.md)。

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

## 切换最佳实践
<a name="blue-green-deployments-switching-best-practices"></a>

在切换之前，我们强烈建议您通过完成以下任务来遵循最佳实践：
+ 在绿色环境中彻底测试资源。确保它们正常高效地运行。
+ 监控相关的 Amazon CloudWatch 指标。有关更多信息，请参阅 [在切换之前验证 CloudWatch 指标](#blue-green-deployments-switching-over-cloudwatch)。
+ 确定最佳切换时间。

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

  如果您的数据库集群和数据库实例上有大量连接，请考虑在切换蓝绿部署之前，手动将连接减少到应用程序所需的最低数量。实现此目标的一种方法是创建一个脚本，该脚本监控蓝绿部署的状态，并在检测到状态已更改为 `SWITCHOVER_IN_PROGRESS` 时开始清理连接。
+ 确保两个环境中的数据库集群和数据库实例均处于 `Available` 状态。
+ 确保绿色环境中的数据库集群运行状况良好且正在复制。
+ 确保您的网络和客户端配置不会将 DNS 缓存存活时间（TTL）增加到五秒以上，这是 Aurora DNS 区域的默认值。否则，应用程序将在切换后继续向蓝色环境发送写入流量。
+ 对于使用逻辑复制的 Aurora PostgreSQL 蓝绿部署，执行以下操作：
  + 在切换之前，请查看逻辑复制限制并采取任何必需的操作。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。
  + 运行 `ANALYZE` 操作以刷新 `pg_statistics` 表。这样可以降低切换后出现性能问题的风险。
  + 在启动蓝绿部署切换之前，请验证您的应用程序没有在会话级别覆盖 `default_transaction_read_only` 参数。在切换期间，此参数在绿色环境写入器上设置为 `on`，以防止在升级完成之前写入。如果您的应用程序或事务将此配置覆盖为 `off`，则应用程序可能会在切换过程中向绿色环境写入数据。如果切换必须回滚，则这些写入在蓝色环境中不可用，要求您手动解决数据不一致问题。我们强烈建议您在继续切换之前审计应用程序查询，以确保它们遵循 `default_transaction_read_only` 设置。

**注意**  
在切换期间，您无法修改切换中包含的任何数据库集群。

## 在切换之前验证 CloudWatch 指标
<a name="blue-green-deployments-switching-over-cloudwatch"></a>

在切换蓝绿部署之前，建议您检查 Amazon CloudWatch 中以下指标的值。
+ `DatabaseConnections` – 使用此指标估算蓝绿部署上的活动水平，并在切换之前确保该值处于部署的可接受水平。如果开启了性能详情，则 `DBLoad` 是更准确的指标。
+ `ActiveTransactions` – 如果在任何数据库实例的数据库参数组中 `innodb_monitor_enable` 设置为 `all`，请使用此指标来查看是否存在大量可能阻止切换的活跃事务。

有关更多信息，请参阅 [Amazon Aurora 的 Amazon CloudWatch 指标](Aurora.AuroraMonitoring.Metrics.md)。

## 在切换之前监控副本滞后
<a name="blue-green-deployments-monitor-replica-lag"></a>

在您切换蓝绿部署之前，请确保副本滞后接近于零，以减少停机时间。

### Aurora MySQL
<a name="blue-green-deployments-monitor-replica-lag-ms-mdb"></a>

对于 MySQL 蓝绿部署，请在绿色环境中检查 `AuroraBinlogReplicaLag` CloudWatch 指标，以确定当前的副本滞后。有关更多信息，请参阅 [诊断并解决只读副本之间的滞后](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。

### Aurora PostgreSQL
<a name="blue-green-deployments-monitor-replica-lag-pg"></a>

对于的 PostgreSQL 蓝绿部署，请在蓝色环境中检查 `OldestReplicationSlotLag` CloudWatch 指标，以确定当前的副本滞后。有关更多信息，请参阅 [Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。

此外，您还可以在蓝色环境中运行以下 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，则表示已捕获副本。

## 切换蓝绿部署
<a name="blue-green-deployments-switching-over"></a>

您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 切换蓝绿部署。

### 控制台
<a name="blue-green-deployments-switching-console"></a>

**切换蓝绿部署**

1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。

1. 在导航窗格中，选择 **Databases**（数据库），然后选择要切换的蓝绿部署。

1. 对于 **Actions**（操作），选择 **Switch over**（切换）。

   将出现 **Switch over**（切换）页面。  
![\[切换蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switch-over-aurora.png)

1. 在 **Switch over**（切换）页面上，查看切换摘要。确保两个环境中的资源都符合您的期望。如果不符合预期，请选择 **Cancel**（取消）。

1. 对于**超时设置**，输入切换的时间限制。

1. 如果您的集群运行 Aurora PostgreSQL，请查看并确认切换前建议。有关更多信息，请参阅 [蓝绿部署的特定于逻辑复制的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

1. 选择 **Switch over**（切换）。

### AWS CLI
<a name="blue-green-deployments-switching-cli"></a>

要使用 AWS CLI 切换蓝绿部署，请使用带有以下选项的 [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) 命令：
+ `--blue-green-deployment-identifier` – 指定蓝绿部署的资源 ID。
+ `--switchover-timeout` – 指定切换的时间限制，以秒为单位。默认值为 300。

**Example 切换蓝绿部署**  
对于 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
```

### RDS API
<a name="blue-green-deployments-switching-api"></a>

要使用 Amazon RDS API 切换蓝绿部署，请使用带有以下参数的 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) 操作：
+ `BlueGreenDeploymentIdentifier` – 指定蓝绿部署的资源 ID。
+ `SwitchoverTimeout` – 指定切换的时间限制，以秒为单位。默认值为 300。

## 切换后
<a name="blue-green-deployments-switching-after"></a>

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

RDS 通过在当前资源名称后面附加 `-oldn`（其中 `n` 是一个数字）来重命名蓝色环境中的数据库集群和数据库实例。蓝色数据库集群被强制进入只读状态。即使您启用了写入操作，它仍为只读的，直到您删除蓝绿部署。RDS 会命名绿色环境 `-newn` 中的数据库集群和数据库实例。

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

![\[切换蓝绿部署之后\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-after-switchover-aurora.png)


### 更新使用者的父节点
<a name="blue-green-deployments-switching-reparent"></a>

RDS 提供完全托管式只读副本。但是，它还提供用于设置自托管式副本（也称为*外部副本*）的选项。外部副本允许您使用第三方资源作为复制目标。

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

**更新父节点**

1. 切换后，之前处于绿色环境中的写入器数据库实例会发出一个事件，其中包含主日志文件名和主日志位置。要找到该事件，请导航到 RDS 控制台，然后从左侧导航窗格中选择**事件**。

1. 在切换之前，按源为旧绿色写入器数据库实例名称的事件进行筛选。

1. 找到包含二进制日志坐标的事件。事件消息类似于：`Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`。

1. 确保使用者或副本已应用来自旧蓝色环境的所有二进制日志。然后，使用提供的二进制日志坐标在使用者上恢复复制。例如，如果您在 EC2 上运行 MySQL 副本，则可以使用下列命令：

   **MySQL 8.0.22 及更低的主要和次要版本**

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

   **MySQL 8.0.23 及更高的主要和次要版本**

   ```
   CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
   ```

# 删除 Amazon Aurora 中的蓝绿部署
<a name="blue-green-deployments-deleting"></a>

您可以在切换蓝绿部署之前或之后将其删除。

当您在切换蓝绿部署之前将其删除时，Amazon RDS 会在绿色环境中可选删除数据库集群：
+ 如果您选择在绿色环境中删除数据库集群（`--delete-target`），则该集群必须已关闭删除保护功能。
+ 如果您不删除绿色环境中的数据库集群（`--no-delete-target`），则集群会被保留，但它不再是蓝绿部署的一部分。对于 Aurora MySQL，将继续在环境之间进行复制。对于 Aurora PostgreSQL，绿色环境将提升为独立环境，因此复制停止。

[切换](blue-green-deployments-switching.md)后，控制台中不提供用于删除绿色数据库的选项。使用 AWS CLI 删除蓝绿部署时，如果部署[状态](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BlueGreenDeployment.html)为 `SWITCHOVER_COMPLETED`，则无法指定 `--delete-target` 选项。

**重要**  
删除蓝绿部署后，RDS 会移除先前生产数据库集群的只读保护。如果对数据库集群禁用了 `read_only` 参数，它将再次开始支持写入操作。

您可以使用 AWS 管理控制台、AWS CLI 或 RDS API 删除蓝绿部署。

## 控制台
<a name="blue-green-deployments-deleting-console"></a>

**删除蓝绿部署**

1. 登录 AWS 管理控制台 并通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)。

1. 在导航窗格中，选择 **Databases**（数据库），然后选择要删除的蓝绿部署。

1. 对于**操作**，选择**删除**。

   将显示**是否删除蓝绿部署？**窗口。  
![\[删除蓝绿部署\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-delete-aurora.png)

   要删除绿色数据库，请选择**删除此蓝绿部署中的绿色数据库**。

1. 在框中输入 **delete me**。

1. 选择 **Delete**。

## AWS CLI
<a name="blue-green-deployments-deleting-cli"></a>

要使用 AWS CLI 删除蓝绿部署，请使用带有以下选项的 [delete-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-blue-green-deployment.html) 命令：
+ `--blue-green-deployment-identifier` – 要删除的蓝绿部署的资源 ID。
+ `--delete-target` – 指定删除绿色环境中的数据库集群。如果蓝绿部署的状态为 `SWITCHOVER_COMPLETED`，则无法指定此选项。
+ `--no-delete-target` – 指定保留绿色环境中的数据库集群。

**Example 删除蓝绿部署和绿色环境中的数据库集群**  
对于 Linux、macOS 或 Unix：  

```
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --delete-target
```
对于：Windows  

```
aws rds delete-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --delete-target
```

**Example 删除蓝绿部署，但保留绿色环境中的数据库集群**  
对于 Linux、macOS 或 Unix：  

```
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --no-delete-target
```
对于：Windows  

```
aws rds delete-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --no-delete-target
```

## RDS API
<a name="blue-green-deployments-deleting-api"></a>

要使用 Amazon RDS API 删除蓝绿部署，请使用带有以下参数的 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html) 操作：
+ `BlueGreenDeploymentIdentifier` – 要删除的蓝绿部署的资源 ID。
+ `DeleteTarget` – 指定 `TRUE` 以删除绿色环境中的数据库集群，或指定 `FALSE` 以保留它。如果蓝绿部署的状态为 `SWITCHOVER_COMPLETED`，则不能为 `TRUE`。