# 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)。