# Amazon Aurora 蓝绿部署概述
通过使用 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)
## 区域和版本可用性
功能可用性和支持因每个数据库引擎的特定版本以及 AWS 区域而异。有关更多信息，请参阅 [支持蓝绿部署的区域和 Aurora 数据库引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md)。
## 使用 Amazon RDS 蓝绿部署的优势
通过使用 Amazon RDS 蓝绿部署，您可以随时了解最新的安全补丁，提高数据库性能，并在短暂且可预测的停机时间内采用更新的数据库功能。蓝绿部署降低了数据库更新（例如主要或次要引擎版本升级）的风险和减少了停机时间。
蓝绿部署提供以下优势：
+ 轻松创建生产就绪的暂存环境。
+ 自动将数据库更改从生产环境复制到暂存环境。
+ 在不影响生产环境的情况下在安全的暂存环境中测试数据库更改。
+ 通过数据库补丁和系统更新保持最新状态。
+ 实施和测试更新的数据库功能。
+ 在不更改应用程序的情况下，将您的暂存环境切换为新的生产环境。
+ 使用内置切换防护机制安全切换。
+ 消除切换期间的数据丢失。
+ 快速切换，通常不到一分钟，具体取决于您的工作负载。
## 蓝绿部署的工作流
使用蓝绿部署进行 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 蓝绿部署操作
用户必须具有所需的权限才能执行与蓝绿部署相关的操作。您可以创建 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 蓝绿部署的其它权限
为 Aurora Global Database 集群创建蓝绿部署时，除了上面列出的权限外，用户还需要以下权限才能执行管理全局集群拓扑的操作。
创建蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:CreateGlobalCluster`
切换蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`
删除蓝绿部署的用户必须具有执行以下 RDS 操作的权限：
+ `rds:DeleteGlobalCluster`
# Amazon Aurora 蓝绿部署的限制和注意事项
要在 Amazon RDS 中进行蓝绿部署，需要仔细考虑复制插槽、资源管理、实例大小以及对数据库性能的潜在影响等因素。以下各节提供的指导有助于您优化部署策略，以确保尽可能地减少停机时间、实现无缝过渡并有效地管理数据库环境。
**Topics**
+ [蓝绿部署的限制](#blue-green-deployments-limitations)
+ [蓝绿部署的 Aurora Global Database 限制](#blue-green-deployments-limitations-agd)
+ [蓝绿部署注意事项](#blue-green-deployments-consider)
## 蓝绿部署的限制
以下限制适用于蓝绿部署。
**Topics**
+ [蓝绿部署的一般限制](#blue-green-deployments-limitations-general)
+ [Aurora MySQL 蓝绿部署的限制](#blue-green-deployments-limitations-mysql)
+ [采用逻辑复制的 Aurora PostgreSQL 蓝绿部署的](#blue-green-deployments-limitations-postgres-logical)
### 蓝绿部署的一般限制
以下一般限制适用于蓝绿部署：
+ 您无法停止和启动属于蓝绿部署一部分的集群。
+ 蓝绿部署不支持使用 AWS Secrets Manager 管理主用户密码。
+ 如果您尝试对蓝色数据库集群强制执行回溯，则蓝绿部署会中断并阻止切换。
+ 在切换期间，蓝色和绿色环境无法与 Amazon Redshift 进行零 ETL 集成。您必须先删除集成，接着切换，然后重新创建集成。
+ 创建蓝绿部署时，必须在绿色环境中禁用事件调度器（`event_scheduler` 参数）。这样可以防止在绿色环境中生成事件并导致不一致。
+ 在蓝色数据库集群上配置的自动扩缩策略不会复制到绿色环境。无论它们最初是在蓝色还是绿色环境中设置的，切换之后都必须重新配置。
+ 您无法将未加密的数据库集群更改为加密的数据库集群。此外，无法将加密的数据库集群更改为未加密的数据库集群。
+ 无法将蓝色数据库集群更改为比其相应的绿色数据库集群更高的引擎版本。
+ 蓝色环境和绿色环境中的资源必须位于同一个 AWS 账户中。
+ 以下功能不支持蓝绿部署：
+ Amazon RDS 代理
+ 跨区域只读副本
+ Aurora Serverless v1 数据库集群
+ CloudFormation
### Aurora MySQL 蓝绿部署的限制
以下限制适用于 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 蓝绿部署的
以下限制适用于使用逻辑复制的 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)。
#### 蓝绿部署的特定于逻辑复制的限制
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 限制
除了上述常规限制和引擎特定的限制外，Aurora Global Database 的蓝绿部署还存在以下限制：
+ 所有操作都必须从与 Global Database 的写入器集群相同的区域启动。
+ 执行全局切换或全局失效转移将导致活动的蓝绿部署失效。需要从新的主要区域中删除并重新创建蓝绿部署。
+ 对于 Aurora PostgreSQL，如果您在生产环境中启用了全局写入转发并创建了蓝绿部署，则在绿色集群上禁用写入转发。只有在蓝绿切换后，当绿色环境变为新的生产环境时，才能在绿色环境中启用写入转发。切换后，写入转发在 `-old1` 集群上处于禁用状态。
+ 在创建蓝绿部署后修改全球数据库的拓扑将导致活动的蓝绿部署失效。必须从新的主要区域中删除并重新创建蓝绿部署。
+ 自动快照按最初在旧的蓝色环境中配置的备份保留天数保留。来自旧的蓝色集群的自动快照不会复制到绿色。
+ 在蓝绿切换期间支持全局失效转移，但在蓝绿切换期间不支持全局切换。
+ 确保所有辅助区域中都存在绿色环境的数据库集群和数据库参数组（名称相同）。如果任何区域中的参数组不可用，则使用这些区域中的默认参数组。
+ 在蓝绿部署切换期间，避免在任何全球数据库成员上使用 RDS 代理。
## 蓝绿部署注意事项
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 蓝绿部署最佳实践
以下是蓝绿部署的最佳实践。
**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)
## 蓝绿部署的一般最佳实践
在创建蓝绿部署时，请考虑以下一般最佳实践。
+ 切换之前，在绿色环境中全面测试 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 蓝绿部署最佳实践
从 Aurora MySQL 数据库集群创建蓝绿部署时，请考虑以下最佳实践。
+ 如果绿色环境出现副本滞后，请考虑以下事项：
+ 如果不需要保留二进制日志，请将其禁用，或者在复制赶上进度之前暂时将其禁用。为此，将 `binlog_format` 数据库集群参数重新设置为 `0`，然后重启绿色写入器数据库实例。
+ 在绿色数据库参数组中临时将 `innodb_flush_log_at_trx_commit` 参数设置为 `0`。当复制赶上进度之后，请在切换之前恢复为默认值 `1`。如果使用临时参数值时发生意外关闭或崩溃，请重建绿色环境以避免未检测到的数据损坏。有关更多信息，请参阅[配置刷新日志缓冲区的频率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。
## Aurora PostgreSQL 蓝绿部署最佳实践
从 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 蓝绿部署最佳实践
除了上面列出的常规和特定于引擎的最佳实践外，还可考虑以下适用于 Aurora Global Database 的最佳实践。
+ 监控以下 CloudWatch 指标，以确定您的生产环境中活动较少的时段：
+ `DatabaseConnections`
+ `ActiveTransactions`
将蓝绿切换安排在计划的维护时段或活动较少的时段。
+ 蓝绿切换持续时间因工作负载和辅助区域的数量而异。当您启动蓝绿切换时，服务会等待副本滞后达到零之后，才会继续操作。我们建议在启动切换之前检查副本滞后。
+ 如果您打算在绿色环境中使用的数据库参数或数据库集群参数组与默认数据库参数或数据库集群参数组不同，请在启动蓝绿部署之前，在所有辅助区域中创建具有相同名称的所需参数组。