# 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`

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