Amazon Aurora 蓝绿部署的限制和注意事项 - Amazon Aurora
限制注意事项

Amazon Aurora 蓝绿部署的限制和注意事项

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

蓝绿部署的限制

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

蓝绿部署的一般限制

以下一般限制适用于蓝绿部署：

  • 您无法停止和启动属于蓝绿部署一部分的集群。

  • 蓝绿部署不支持使用 AWS Secrets Manager 管理主用户密码。

  • 如果您尝试对蓝色数据库集群强制执行回溯，则蓝绿部署会中断并阻止切换。

  • 在切换期间，蓝色和绿色环境无法与 Amazon Redshift 进行零 ETL 集成。您必须先删除集成，接着切换，然后重新创建集成。

  • 创建蓝绿部署时，必须在绿色环境中禁用事件调度器（event_scheduler 参数）。这样可以防止在绿色环境中生成事件并导致不一致。

  • 在蓝色数据库集群上配置的自动扩缩策略不会复制到绿色环境。无论它们最初是在蓝色还是绿色环境中设置的，切换之后都必须重新配置。

  • 您无法将未加密的数据库集群更改为加密的数据库集群。此外，无法将加密的数据库集群更改为未加密的数据库集群。

  • 无法将蓝色数据库集群更改为比其相应的绿色数据库集群更高的引擎版本。

  • 蓝色环境和绿色环境中的资源必须位于同一个 AWS 账户中。

  • 以下功能不支持蓝绿部署：

    • Amazon RDS 代理

    • 跨区域只读副本

    • Aurora Serverless v1 数据库集群

    • 属于 Aurora Global Database 的数据库集群

    • AWS CloudFormation

Aurora MySQL 蓝绿部署的限制

以下限制适用于 Aurora MySQL 蓝绿部署：

  • 源数据库集群不能包含任何名为 tmp 的数据库。具有此名称的数据库将不会复制到绿色环境中。

  • 蓝色数据库集群不能是外部二进制日志副本。

  • 如果源数据库集群启用了回溯功能，则创建的绿色数据库集群不支持回溯功能。这是因为回溯功能不适用于二进制日志（binlog）复制，而二进制日志复制是蓝绿部署所必需的。有关更多信息，请参阅 回溯 Aurora 数据库集群。

  • 蓝绿部署不支持适用于 MySQL 的 AWS JDBC 驱动程序。有关更多信息，请参阅 GitHub 上的 Known Limitations。

采用逻辑复制的 Aurora PostgreSQL 蓝绿部署的

以下限制适用于使用逻辑复制的 Aurora PostgreSQL 蓝绿。

  • 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 执行计划。

  • 以下限制适用于 PostgreSQL 扩展：

    • 创建蓝绿部署时，必须在蓝色环境中禁用 pg_partman 扩展。该扩展将执行 CREATE TABLE 等 DDL 操作，这会中断从蓝色环境到绿色环境的逻辑复制。

    • 创建蓝绿部署后，pg_cron 扩展必须在所有绿色数据库上保持禁用状态。该扩展具有以超级用户身份运行并绕过绿色环境只读设置的后台工作进程，这可能会导致复制冲突。

    • 在所有绿色数据库上，apg_plan_mgmt 扩展必须将 apg_plan_mgmt.capture_plan_baselines 参数设置为 off，以免在蓝色环境中捕获相同的计划时发生主键冲突。有关更多信息，请参阅 Aurora PostgreSQL 查询计划管理概览。

    • 创建蓝绿部署时，必须在蓝色环境中禁用 pglogical 和 pgactive 扩展。将绿色环境切换为新的生产环境后，您可以重新启用这些扩展。此外，蓝色数据库不能是外部实例的逻辑订阅者。

    • 如果您使用的是 pgAudit 扩展，则它必须保留在蓝色和绿色数据库实例的自定义数据库参数组上的共享库（shared_preload_libraries）中。有关更多信息，请参阅 设置 pgAudit 扩展。

蓝绿部署的特定于逻辑复制的限制

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

下表描述了适用于 Aurora PostgreSQL 的蓝绿部署的逻辑复制限制。

限制 说明
数据定义语言（DDL）语句，（例如 CREATE TABLE 和 CREATE SCHEMA）不会从蓝色环境复制到绿色环境。

如果 Aurora 在蓝色环境中检测到 DDL 更改，则您的绿色数据库将进入复制已降级状态。必须删除蓝绿部署和所有绿色数据库，然后重新创建。
对序列对象执行的 NEXTVAL 操作在蓝色环境和绿色环境之间不同步。

在切换期间，Aurora 会增加绿色环境中的序列值，以匹配蓝色环境中的那些序列值。如果您有成千上万的序列，这可能会延迟切换。
在蓝色环境中创建或修改大型对象不会复制到绿色环境中。

如果 Aurora 检测到在蓝色环境中创建或修改了存储在 pg_largeobject 系统表中的大型对象，则您的绿色数据库将进入复制已降级状态。必须删除蓝绿部署和所有绿色数据库，然后重新创建。

刷新实体化视图会导致复制中断。

在蓝色环境中刷新实体化视图，会中断向绿色环境的复制。请避免在蓝色环境中刷新实体化视图。切换后，您可以使用 REFRESH MATERIALIZED VIEW 命令手动刷新实体化视图，也可以按计划进行刷新。

不允许对没有主键的表执行 UPDATE 和 DELETE 操作。

在创建蓝绿部署之前，请确保数据库集群中的所有表都有主键。

有关更多信息，请参阅 PostgreSQL 逻辑复制文档中的限制。

蓝绿部署注意事项

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 调用。

  • 如果您将数据库活动流用于蓝色环境中的资源，请调整您的应用程序以在切换后监视新流的数据库事件。有关更多信息，请参阅 支持数据库活动流的区域和 Aurora 数据库引擎。

  • 如果您使用性能详情API，请在切换后调整 API 调用中的资源 ID。有关更多信息，请参阅 在 Amazon Aurora 上使用性能详情监控数据库负载。

    您可以在切换后监控同名数据库，但它不包含切换之前的数据。

  • 如果您在 IAM 策略中使用资源 ID，请确保在必要时添加新转换的资源的资源 ID。有关更多信息，请参阅 Amazon Aurora 的 Identity and Access Management。

  • 如果您有与数据库集群关联的 IAM 角色，请务必在切换后重新关联它们。附加的角色不会自动复制到绿色环境。

  • 如果您使用 IAM 数据库身份验证对数据库集群进行身份验证，请确保用于数据库访问的 IAM 策略同时包含在策略的 Resource 元素下方列出的蓝色和绿色数据库。这是在切换后连接到绿色数据库所必需的。有关更多信息，请参阅 创建和使用适用于 IAM 数据库访问的 IAM 策略。

  • 如果您想为属于蓝绿部署的数据库集群还原手动数据库集群快照，请确保通过检查快照拍摄时间来还原正确的数据库集群快照。有关更多信息，请参阅 从数据库集群快照还原。

  • 切换后，AWS Database Migration Service（AWS DMS）复制任务无法恢复，因为蓝色环境中的检查点在绿色环境中无效。您必须使用新的检查点重新创建 DMS 任务后才能继续复制。

  • Amazon Aurora 通过在蓝色环境中克隆底层 Aurora 存储卷来创建绿色环境。绿色集群卷仅存储对绿色环境所做的增量更改。如果您删除蓝色环境中的数据库集群，则绿色环境中底层 Aurora 存储卷的大小增长到完全大小。有关更多信息，请参阅 克隆 Amazon Aurora 数据库集群卷。

  • 当您在蓝绿部署的绿色环境中向数据库集群添加数据库实例时，当您切换时，新的数据库实例不会替换蓝色环境中的数据库实例。但是，新的数据库实例保留在数据库集群中，并成为新的生产环境中的数据库实例。

  • 在蓝绿部署的绿色环境中删除数据库集群中的数据库实例时，您无法创建新的数据库实例来替换蓝绿部署中的该实例。

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

    如果您在绿色环境中删除数据库集群中的数据库实例，则会导致以下行为：

    • 如果蓝色环境中存在同名的数据库实例，则不会将其切换到绿色环境中的数据库实例。不会通过将 -oldn 附加到数据库实例名称来重命名此数据库实例。

    • 切换后，任何指向蓝色环境中数据库实例的应用程序都将继续使用相同的数据库实例。