本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 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 全域資料庫藍/綠部署最佳實務](#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\_stat\_replication\_slots](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`。否則，複寫系統會傳播變更與執行觸發條件，而會導致複寫。
+ 長時間執行的交易可能會導致嚴重的複本延遲。若要縮短複本延遲，請考慮執行下列動作：
  + 減少長時間執行的交易和子交易，這些交易可能會延遲，直到綠色環境趕上藍色環境為止。
  + 減少藍色環境的大量操作，直到綠色環境趕上藍色環境為止。
  + 在建立藍/綠部署之前，對忙碌資料表啟動手動清空凍結操作。如需說明，請參閱[執行手動清空凍結](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html)。
  + 在 PostgreSQL 第 12 版及更新版本中，停用大型或忙碌資料表的 `index_cleanup` 參數，以提高藍色資料庫定期維護的效率。如需詳細資訊，請參閱[盡快清空資料表](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing)。
**注意**  
在清空期間定期略過索引清除可能會導致索引膨脹，而可能會掃描效能下降。根據最佳實務，只有在使用藍/綠部署時，才使用此方法。部署完成後，建議您繼續定期維護和清除索引。
  + 如果工作負載的藍色和綠色資料庫執行個體大小過小，則可能會發生複本延遲。確保資料庫執行個體未達到執行個體類型的資源限制。如需詳細資訊，請參閱[使用 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\_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 的資料庫叢集參數群組設定](babelfish-configuration.md)。

## Aurora 全域資料庫藍/綠部署最佳實務
<a name="blue-green-deployments-best-practices-agd"></a>

除了上述一般和引擎特定最佳實務之外，請考慮 Aurora Global Database 的最佳實務。 
+ 監控下列 CloudWatch 指標，以識別生產環境中活動量低的期間：
  + `DatabaseConnections`
  + `ActiveTransactions`

  在計劃的維護時段或活動量低的期間，安排藍/綠轉換。
+ 藍/綠轉換持續時間取決於您的工作負載和次要區域的數量。當您啟動藍/綠切換時，服務會等待複本延遲達到零，然後再繼續。我們建議您在開始切換之前檢查複本延遲。
+ 如果您想要使用綠色環境預設參數以外的資料庫參數或資料庫叢集參數群組，請先在所有次要區域中建立名稱相同的所需參數群組，再啟動藍/綠部署。