蓝绿部署的最佳实践
以下是蓝绿部署的最佳实践。
蓝绿部署的一般最佳实践
在创建蓝绿部署时,请考虑以下一般最佳实践。
-
切换之前,在绿色环境中全面测试 Aurora 数据库集群。
-
使绿色环境中的数据库保持只读。建议您在绿色环境中谨慎启用写入操作,因为它们可能导致复制冲突。它们还可能导致切换后生产数据库中出现意外数据。
-
使用蓝绿部署实现模式更改时,仅进行与复制兼容的更改。
例如,您可以在表末尾添加新列,而无需中断从蓝色部署到绿色部署的复制。但是,模式更改(例如重命名列或重命名表)会中断向绿色部署的复制。
有关与复制兼容的更改的更多信息,请参阅 MySQL 文档中的在源和副本上使用不同的表定义进行复制
以及 PostgreSQL 逻辑复制文档中的限制 。 -
为两个环境中的所有连接使用集群端点、读取器端点或自定义端点。请勿使用带有静态或排除列表的实例端点或自定义端点。
-
切换蓝绿部署时,请遵循切换最佳实践。有关更多信息,请参阅切换最佳实践。
Aurora MySQL 蓝绿部署最佳实践
从 Aurora MySQL 数据库集群创建蓝绿部署时,请考虑以下最佳实践。
-
如果绿色环境出现副本滞后,请考虑以下事项:
-
如果不需要保留二进制日志,请将其禁用,或者在复制赶上进度之前暂时将其禁用。为此,将
binlog_format
数据库集群参数重新设置为0
,然后重启绿色写入器数据库实例。 -
在绿色数据库参数组中将
innodb_flush_log_at_trx_commit
参数临时设置为 1。当复制赶上进度之后,请在切换之前恢复为默认值。如果发生意外关闭或崩溃并显示临时参数值,请重建绿色环境以避免未检测到的数据损坏。有关更多信息,请参阅配置刷新日志缓冲区的频率。
-
Aurora PostgreSQL 蓝绿部署最佳实践
从 Aurora PostgreSQL 数据库集群创建蓝绿部署时,请考虑以下的最佳实践。
-
监控 Aurora PostgreSQL 逻辑复制直写缓存,并在必要时对缓存缓冲区进行调整。有关更多信息,请参阅监控 Aurora PostgreSQL 逻辑复制直写缓存。
-
在蓝色环境中增加
logical_decoding_work_mem
数据库参数的值。这样做可以减少磁盘上的解码次数,改为使用内存。有关更多信息,请参阅调整工作内存以进行逻辑解码。-
您可以使用
ReplicationSlotDiskUsage
CloudWatch 指标监控写入磁盘的事务溢出量。该指标提供对复制槽的磁盘使用情况的见解,有助于确定事务数据何时超过内存容量并存储在磁盘上。您可以使用FreeableMemory
CloudWatch 指标监控可用内存。有关更多信息,请参阅Amazon Aurora 的实例级指标。 -
在 Aurora PostgreSQL 版本 14 及更高版本中,您可以使用
pg_stat_replication_slots
系统视图监控逻辑溢出文件的大小。
-
-
创建蓝绿部署之前,请将所有 PostgreSQL 扩展更新到最新版本。有关更多信息,请参阅升级 PostgreSQL 扩展。
-
如果您使用的是
aws_s3
扩展,请在创建绿色环境之后,通过 IAM 角色赋予绿色数据库集群访问 Amazon S3 的权限。这允许导入和导出命令在切换后继续运行。有关说明,请参阅 设置 Amazon S3 存储桶的访问权限。 -
如果您为绿色环境指定更高的引擎版本,请对所有数据库运行
ANALYZE
操作来刷新pg_statistic
表。在主要版本升级期间不会传输优化程序统计数据,因此您必须重新生成所有统计数据,来避免出现性能问题。有关主要版本升级期间的其他最佳实践,请参阅执行主要版本升级。 -
如果在源中使用触发器来操作数据,请避免将触发器配置为
ENABLE REPLICA
或ENABLE ALWAYS
。否则,复制系统会传播更改并执行触发器,从而导致重复。 -
长时间运行的事务可能会导致严重的副本延迟。要减少副本延迟,可考虑执行下列操作:
-
减少长期运行的事务和子事务,这些事务和子事务可能会延迟到绿色环境赶上蓝色环境之后再运行。
-
减少蓝色环境上的批量操作,直到绿色环境赶上蓝色环境之后再运行。
-
在创建蓝绿部署之前,对事务繁忙的表启动手动真空冻结操作。有关说明,请参阅执行手动 vacuum 冻结。
-
在 PostgreSQL 12 及更高版本中,请对大型表或繁忙表禁用
index_cleanup
参数,以提高蓝色数据库的常规维护效率。有关更多信息,请参阅尽快对表执行 vacuum 操作。注意
在执行 vacuum 操作期间定期跳过索引清理可能会导致索引膨胀,从而降低扫描性能。最佳实践是仅在使用蓝绿部署时使用此方法。部署完成后,建议恢复定期的索引维护和清理。
-
如果蓝色和绿色数据库实例的大小不足以应付工作负载,则可能会出现副本延迟。确保您的数据库实例未达到该实例类型的资源限制。有关更多信息,请参阅使用 Amazon CloudWatch 指标分析 Aurora PostgreSQL 的资源使用情况。
-
-
复制缓慢会导致发送方和接收方经常重启,从而延迟同步。要确保它们保持活动状态,请在蓝色环境中将
wal_sender_timeout
参数设置为0
,在绿色环境中将wal_receiver_timeout
参数设置为0
,从而禁用超时。 -
检查 UPDATE 和 DELETE 语句的性能,并评估在 WHERE 子句中使用的列上创建索引能否优化这些查询。在绿色环境中重播操作时,这可以提高性能。有关更多信息,请参阅检查谓词筛选条件是否存在生成等待的查询。
-
如果您使用的是触发器,请确保它们不会影响名称以“rds”开头的
pg_catalog.pg_publication
、pg_catalog.pg_subscription
和pg_catalog.pg_replication_slots
对象的创建、更新及删除。 -
如果在源数据库集群上启用了 Babelfish,则绿色环境的目标数据库集群参数组中以下参数的设置必须与源数据库集群参数组中的设置相同:
-
rds.babelfish_status
-
babelfishpg_tds.tds_default_numeric_precision
-
babelfishpg_tds.tds_default_numeric_scale
-
babelfishpg_tsql.default_locale
-
babelfishpg_tsql.migration_mode
-
babelfishpg_tsql.server_collation_name
有关这些参数的更多信息,请参阅 Babelfish 的数据库集群参数组设置。
-