# Amazon RDS 蓝绿部署最佳实践
以下是蓝绿部署的最佳实践。
**Topics**
+ [
## 蓝绿部署的一般最佳实践
](#blue-green-deployments-best-practices-general)
+ [
## RDS for MySQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-mysql)
+ [
## RDS for MySQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-agd)
+ [
# PostgreSQL 蓝绿部署的复制方法
](blue-green-deployments-replication-type.md)
## 蓝绿部署的一般最佳实践
在创建蓝绿部署时，请考虑以下一般最佳实践。
+ 切换之前，在绿色环境中全面测试数据库实例 。
+ 使绿色环境中的数据库保持只读。建议您在绿色环境中谨慎启用写入操作，因为它们可能导致复制冲突。它们还可能导致切换后生产数据库中出现意外数据。
+ 如果您使用蓝绿部署来实现架构更改，则仅进行与复制兼容的更改。
例如，您可以在表末尾添加新列，而无需中断从蓝色部署到绿色部署的复制。但是，模式更改（例如重命名列或重命名表）会中断向绿色部署的复制。
有关与复制兼容的更改的更多信息，请参阅 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)。
**注意**
此限制不适用于使用物理复制的 RDS for PostgreSQL 蓝绿部署。有关更多信息，请参阅 [采用物理复制的 RDS for PostgreSQL 蓝绿部署的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)。
+ 创建蓝绿部署后，必要时处理延迟加载。切换之前，请确保数据加载已完成。有关更多信息，请参阅 [蓝绿部署的延迟加载和存储初始化](blue-green-deployments-creating.md#blue-green-deployments-creating-lazy-loading)。
+ 切换蓝绿部署时，请遵循切换最佳实践。有关更多信息，请参阅 [切换最佳实践](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices)。
## RDS for MySQL 蓝绿部署最佳实践
从 RDS for MySQL 数据库实例创建蓝绿部署时，请考虑以下最佳实践。
+ 避免使用未针对复制进行优化的非事务性存储引擎，例如 MyISAM。
+ 针对二进制日志复制优化只读副本和绿色环境。如果您的数据库引擎支持，请在创建蓝绿部署之前，先启用 GTID、并行复制和崩溃安全复制，以确保数据一致性和持久性。有关更多信息，请参阅 [使用基于 GTID 的复制](mysql-replication-gtid.md)。
+ 如果绿色环境出现副本滞后，请考虑以下事项：
+ 在绿色数据库参数组中临时将 `innodb_flush_log_at_trx_commit` 参数设置为 `2`。当复制赶上进度之后，请在切换之前恢复为默认值 `1`。如果使用临时参数值时发生意外关闭或崩溃，请重建绿色环境以避免未检测到的数据损坏。
+ 为减少写入延迟和提高复制吞吐量，可临时将绿色多可用区数据库实例改为单可用区数据库实例。切换前重新启用多可用区。
## RDS for MySQL 蓝绿部署最佳实践
除了上面列出的常规和特定于引擎的最佳实践外，还可考虑以下适用于 RDS for MySQL 数据库实例的最佳实践。
+ 监控以下 CloudWatch 指标，以确定您的生产环境中活动较少的时段：
+ `DatabaseConnections`
+ `ActiveTransactions`
将蓝绿切换安排在计划的维护时段或活动较少的时段。
+ 蓝绿切换持续时间因工作负载和辅助区域的数量而异。当您启动蓝绿切换时，服务会等待副本滞后达到零之后，才会继续操作。我们建议在启动切换之前检查副本滞后。
+ 如果您打算在绿色环境中使用的数据库参数或数据库集群参数组与默认数据库参数或数据库集群参数组不同，请在启动蓝绿部署之前，在所有辅助区域中创建具有相同名称的所需参数组。
### RDS for PostgreSQL 蓝绿部署的最佳实践
从 RDS for PostgreSQL 数据库实例创建蓝绿部署时，请考虑以下最佳实践。
**Topics**
+ [
#### RDS for PostgreSQL 蓝绿部署的一般最佳实践
](#blue-green-deployments-best-practices-postgres-general)
+ [
#### 采用物理复制的 RDS for PostgreSQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-postgres-physical)
+ [
#### 采用逻辑复制的 RDS for PostgreSQL 蓝绿部署最佳实践
](#blue-green-deployments-best-practices-postgres-logical)
#### RDS for PostgreSQL 蓝绿部署的一般最佳实践
从 RDS for PostgreSQL 数据库实例创建蓝绿部署时，请考虑以下一般的最佳实践。
+ 创建蓝绿部署之前，请将所有 PostgreSQL 扩展更新到最新版本。有关更多信息，请参阅 [在 RDS for PostgreSQL 数据库中升级 PostgreSQL 扩展](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)。
+ 长时间运行的事务可能会导致严重的副本延迟。要减少副本延迟，可考虑执行下列操作：
+ 减少长期运行的事务，这些事务可能会延迟到绿色环境赶上蓝色环境之后再运行。
+ 减少蓝色环境上的批量操作，直到绿色环境赶上蓝色环境之后再运行。
+ 在创建蓝绿部署之前，对事务繁忙的表启动手动真空冻结操作。
+ 对于 PostgreSQL 12 及更高版本，请对大型表或繁忙表禁用 `index_cleanup` 参数，以提高蓝色数据库的正常维护速率。有关更多信息，请参阅 [尽快对表执行 vacuum 操作](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)。
**注意**
在执行 vacuum 操作期间定期跳过索引清理可能会导致索引膨胀，从而降低扫描性能。最佳实践是仅在使用蓝绿部署时使用此方法。部署完成后，建议恢复定期的索引维护和清理。
+ 复制缓慢会导致发送方和接收方经常重启，从而延迟同步。要确保它们保持活动状态，请在蓝色环境中将 `wal_sender_timeout` 参数设置为 `0`，在绿色环境中将 `wal_receiver_timeout` 参数设置为 `0`，从而禁用超时。
+ 为防止从蓝色环境中删除预写日志（WAL）段，请将 PostgreSQL 13 及更低版本的 `wal_keep_segments` 参数设置为 15625。对于版本 14 及更高版本，如果有足够的可用存储空间，还可将 `wal_keep_size` 参数设置为 1 TiB。
#### 采用物理复制的 RDS for PostgreSQL 蓝绿部署最佳实践
通过物理复制，Amazon RDS 可创建源数据库实例的只读副本。有关相关参数、监控、调整和故障排除，请参阅[使用 Amazon RDS for PostgreSQL 只读副本](USER_PostgreSQL.Replication.ReadReplicas.md)。
有关蓝绿部署何时使用物理复制而不是逻辑复制的说明，请参阅 [PostgreSQL 蓝绿部署的复制方法](blue-green-deployments-replication-type.md)。
#### 采用逻辑复制的 RDS for PostgreSQL 蓝绿部署最佳实践
在创建使用逻辑复制的蓝绿部署时，请考虑以下最佳实践。有关蓝绿部署何时使用逻辑复制而不是物理复制的说明，请参阅 [PostgreSQL 蓝绿部署的复制方法](blue-green-deployments-replication-type.md)。
+ 如果您的数据库有足够的可用内存，请在蓝色环境中增加 `logical_decoding_work_mem` 数据库参数的值。这样做可以减少磁盘上的解码次数，改为使用内存。有关更多信息，请参阅 [PostgreSQL 文档](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)。
+ 您可以使用 `ReplicationSlotDiskUsage` CloudWatch 指标监控写入磁盘的事务溢出量。该指标提供对复制槽的磁盘使用情况的见解，有助于确定事务数据何时超过内存容量并存储在磁盘上。您可以使用 `FreeableMemory` CloudWatch 指标监控可用内存。有关更多信息，请参阅 [Amazon RDS 的 Amazon CloudWatch 实例级指标](rds-metrics.md#rds-cw-metrics-instance)。
+ 在 RDS for PostgreSQL 版本 14 及更高版本中，您可以使用 `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)` 系统视图监控逻辑溢出文件的大小。
+ 如果您使用的是 `aws_s3` 扩展，请在创建绿色环境之后，通过 IAM 角色赋予绿色数据库实例访问 Amazon S3 的权限。这允许导入和导出命令在切换后继续运行。有关说明，请参阅[设置 Amazon S3 存储桶的访问权限](postgresql-s3-export-access-bucket.md)。
+ 检查 UPDATE 和 DELETE 语句的性能，并评估在 WHERE 子句中使用的列上创建索引能否优化这些查询。在绿色环境中重播操作时，这可以提高性能。
+ 如果您使用的是触发器，请确保它们不会影响名称以“rds”开头的 `pg_catalog.pg_publication`、`pg_catalog.pg_subscription` 和 `pg_catalog.pg_replication_slots` 对象的创建、更新及删除。
+ 如果您为绿色环境指定更高的引擎版本，请对所有数据库运行 `ANALYZE` 操作来刷新 `pg_statistic` 表。在主要版本升级期间不会传输优化程序统计数据，因此您必须重新生成所有统计数据，来避免出现性能问题。有关主要版本升级期间的其他最佳实践，请参阅[如何执行 RDS for PostgreSQL 的主要版本升级](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)。
+ 如果在源中使用触发器来操作数据，请避免将触发器配置为 `ENABLE REPLICA` 或 `ENABLE ALWAYS`。否则，复制系统会传播更改并执行触发器，从而导致重复。
# PostgreSQL 蓝绿部署的复制方法
Amazon RDS for PostgreSQL 的蓝绿部署主要使用物理复制。但是，如果您在创建蓝绿部署时请求主要版本升级，并且您的源数据库实例运行下表所列的 PostgreSQL 版本之一，Amazon RDS 将改用逻辑复制。
下表概述了 Amazon RDS 何时在 PostgreSQL 蓝绿部署中使用物理复制或逻辑复制。
| 源 PostgreSQL 数据库实例版本 | 蓝绿部署中的升级操作 | 复制方法 |
| --- | --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/blue-green-deployments-replication-type.html) | 主要版本升级（绿色实例在比蓝色实例更高的主要引擎版本上） | 逻辑复制 |
| 支持的所有版本 | 次要版本升级，或者不升级（绿色实例在与蓝色实例相同的主要引擎版本上） | 物理复制 |
**注意**
以下 RDS for PostgreSQL 版本的蓝绿部署不支持主要版本升级：版本 15.3 及更低版本、14.8 及更低版本、13.11 及更低版本、12.15 及更低版本或 11.20 及更低版本。
有关使用物理或逻辑复制的蓝绿部署的限制的信息，请参阅以下各节：
+ [采用物理复制的 RDS for PostgreSQL 蓝绿部署的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-physical)
+ [RDS for PostgreSQL 蓝绿部署的限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres-logical)