本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Aurora 藍/綠部署概觀
透過使用 Amazon Aurora 藍/綠部署，您可以進行並測試資料庫變更，然後在生產環境中實作這些變更。*藍/綠部署*會建立一個複製生產環境的預備環境。在藍/綠部署中，*藍色環境*是目前的生產環境。*綠色環境*是預備環境，並與目前生產環境保持同步。
您可以對綠色環境中的 Aurora 資料庫叢集進行變更，而不會影響生產工作負載。例如，您可以升級主要或次要資料庫引擎版本或在預備環境中變更資料庫參數。您可以在綠色環境中徹底測試變更。備妥後，您可以*切換*環境，將綠色環境轉換為新的生產環境。切換通常只需不到一分鐘的時間，不會遺失資料，也不需要變更應用程式。
因為綠色環境是生產環境拓撲的副本，所以資料庫叢集及其所有資料庫執行個體都會在部署中複製。綠色環境也包含資料庫叢集所使用的功能，例如資料庫叢集快照、Performance Insights、增強型監控和 Aurora Serverless v2。
**注意**
Aurora MySQL、Aurora PostgreSQL 和 Aurora Global Database 支援藍/綠部署。如需 Amazon RDS 可用性，請參閱《Amazon RDS 使用者指南》**中的 [Amazon RDS 藍/綠部署概觀](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)。
**Topics**
+ [區域和版本可用性](#blue-green-deployments-region-version-availability)
+ [使用 Amazon RDS 藍/綠部署的優點](#blue-green-deployments-benefits)
+ [藍/綠部署的工作流程](#blue-green-deployments-major-steps)
+ [授予 Amazon Aurora 藍/綠部署操作的存取權](blue-green-deployments-authorizing-access.md)
+ [Amazon Aurora 藍/綠部署的限制和考量事項](blue-green-deployments-considerations.md)
+ [Amazon Aurora 藍/綠部署的最佳實務](blue-green-deployments-best-practices.md)
## 區域和版本可用性
功能可用性和支援會因每個資料庫引擎的特定版本以及 AWS 區域而有所不同。如需詳細資訊，請參閱[藍/綠部署支援的區域和 Aurora 資料庫引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md)。
## 使用 Amazon RDS 藍/綠部署的優點
透過使用 Amazon RDS 藍/綠部署，您可以隨時掌握最新的安全修補程式、改善資料庫效能，以及採用較新的資料庫功能，其停機時間短暫且可預測。藍/綠部署可減少資料庫更新 (例如主要或次要引擎版本升級) 的風險和停機時間。
藍/綠部署提供下列優點：
+ 輕鬆建立生產就緒的預備環境。
+ 自動將資料庫變更從生產環境複寫到預備環境。
+ 在安全預備環境中測試資料庫變更，而不會影響生產環境。
+ 隨時掌握最新的資料庫修補程式和系統更新。
+ 實作和測試較新的資料庫功能。
+ 切換預備環境以成為新的生產環境，而無需對應用程式進行變更。
+ 透過使用內建的防護機制安全切換。
+ 消除切換期間的資料遺失情況。
+ 通常在一分鐘內快速切換，取決於您的工作負載。
## 藍/綠部署的工作流程
當您使用藍/綠部署進行 Aurora 資料庫叢集更新時，請完成下列主要步驟。
1. 識別需要更新的生產資料庫叢集。
下圖顯示生產資料庫叢集的範例。
![\[藍/綠部署中的生產 (藍色) Aurora 資料庫叢集\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png)
1. 建立藍/綠部署。如需說明，請參閱[在 Amazon Aurora 中建立藍/綠部署](blue-green-deployments-creating.md)。
下圖顯示一個範例，說明如何從步驟 1 開始生產環境的藍/綠部署範例。在建立藍/綠部署時，RDS 會複製 Aurora 資料庫叢集的完整拓撲和組態，以建立綠色環境。複製的資料庫叢集和資料庫執行個體名稱都會附加 `-green-random-characters`。影像中的預備環境包含資料庫叢集 (auroradb-green-**abc123**)。它還包含資料庫叢集中的三個資料庫執行個體 (auroradb-instance1-green-**abc123**、auroradb-instance2-green-**abc123** 和 auroradb-instance3-green-**abc123**)。
![\[適用於 Amazon Aurora 的藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png)
建立藍/綠部署時，您可以指定較高的資料庫引擎版本，並針對綠色環境中的資料庫叢集指定不同的資料庫叢集參數群組。您也可以針對資料庫叢集中的資料庫執行個體指定不同的資料庫參數群組。
RDS 也會設定從藍色環境中主要資料庫執行個體到綠色環境中主要資料庫執行個體的複寫。
**重要**
針對 Aurora MySQL 第 3 版，在您建立藍/綠部署之後，綠色環境中的資料庫叢集預設不允許寫入操作。然而，此設定不適用於具有 `CONNECTION_ADMIN` 權限的使用者 (包含 Aurora 主要使用者)。具有此權限的使用者可以覆寫 `read_only` 行為。如需詳細資訊，請參閱[角色型權限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。
1. 對預備環境進行變更。
例如，您可能會變更綠色環境中一或多個資料庫執行個體所使用的資料庫執行個體類別。
如需修改資料庫叢集的詳細資訊，請參閱 [修改 Amazon Aurora 資料庫叢集](Aurora.Modifying.md)。
1. 測試您的預備環境。
在測試期間，建議您將綠色環境中的資料庫保持唯讀狀態。在綠色環境上小心啟用寫入操作，因為它們可能會在綠色環境中造成複寫衝突。它們也可能會在切換後於生產資料庫中產生非預期的資料。若要啟用 Aurora MySQL 的寫入操作，請將 `read_only` 參數設為 `0`，然後重新啟動資料庫執行個體。對於 Aurora PostgreSQL，在工作階段層級將 `default_transaction_read_only` 參數設為 `off`。
1. 備妥後，請切換以將預備環境轉換為新的生產環境。如需說明，請參閱[在 Amazon Aurora 中切換藍/綠部署](blue-green-deployments-switching.md)。
切換會產生停機時間。停機時間通常不到一分鐘，但可能更長，取決於您的工作負載。
下圖顯示切換後的資料庫叢集。
![\[切換 Amazon Aurora 藍/綠部署後的資料庫叢集和資料庫執行個體\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png)
切換後，綠色環境中的 Aurora 資料庫叢集會成為新的生產資料庫叢集。目前生產環境中的名稱和端點會指派給新切換的生產環境，不需要對您的應用程式進行任何變更。因此，您的生產流量現在會流向新的生產環境。藍色環境中的資料庫叢集和資料庫執行個體會重新命名，方法是將 `-oldn` 附加至目前名稱 (其中 `n` 是數字)。例如，假設藍色環境中資料庫執行個體的名稱為 `auroradb-instance-1`。切換後，資料庫執行個體名稱可能是 `auroradb-instance-1-old1`。
在影像的範例中，切換期間會發生下列變更：
+ 綠色環境資料庫叢集 `auroradb-green-abc123` 會成為名為 `auroradb` 的生產資料庫叢集。
+ 名為 `auroradb-instance1-green-abc123` 的綠色環境資料庫執行個體會成為生產資料庫執行個體 `auroradb-instance1`。
+ 名為 `auroradb-instance2-green-abc123` 的綠色環境資料庫執行個體會成為生產資料庫執行個體 `auroradb-instance2`。
+ 名為 `auroradb-instance3-green-abc123` 的綠色環境資料庫執行個體會成為生產資料庫執行個體 `auroradb-instance3`。
+ 名為 `auroradb` 的藍色環境資料庫叢集會成為 `auroradb-old1`。
+ 名為 `auroradb-instance1` 的藍色環境資料庫執行個體會成為 `auroradb-instance1-old1`。
+ 名為 `auroradb-instance2` 的藍色環境資料庫執行個體會成為 `auroradb-instance2-old1`。
+ 名為 `auroradb-instance3` 的藍色環境資料庫執行個體會成為 `auroradb-instance3-old1`。
1. 如果不再需要藍/綠部署，您可以將其刪除。如需說明，請參閱[刪除 Amazon Aurora 中的藍/綠部署](blue-green-deployments-deleting.md)。
切換後，不會刪除先前的生產環境，以便您可以在必要時使用它進行迴歸測試。
# 授予 Amazon Aurora 藍/綠部署操作的存取權
使用者必須具有必要的許可，才能執行與藍/綠部署相關的操作。您可以建立 IAM 政策，許可使用者和角色對其需要的指定資源執行特定 API 操作。然後，您可以將這些政策連線至需要這些許可的 IAM 許可集或角色。如需詳細資訊，請參閱[Amazon Aurora 的 Identity and access management](UsingWithRDS.IAM.md)。
建立藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:CreateBlueGreenDeployment`
+ `rds:AddTagsToResource`
+ `rds:CreateDBCluster`
+ `rds:CreateDBInstance`
+ `rds:CreateDBClusterEndpoint`
切換藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:SwitchoverBlueGreenDeployment`
+ `rds:ModifyDBCluster`
+ `rds:PromoteReadReplicaDBCluster`
刪除藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:DeleteBlueGreenDeployment`
+ `rds:DeleteDBCluster`
+ `rds:DeleteDBInstance`
+ `rds:DeleteDBClusterEndpoint`
Aurora 會代表您佈建和修改預備環境中的資源。這些資源包含使用內部定義命名慣例的資料庫執行個體。因此，連接的 IAM 政策不能包含部分資源名稱模式，例如 `my-db-prefix-*`。僅支援萬用字元 (\$1)。一般而言，建議使用資源標籤和其他支援的屬性 (而不是萬用字元)，來控制對這些資源的存取權。如需詳細資訊，請參閱[適用於 Amazon RDS 的動作、資源和條件索引鍵](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html)。
## Aurora Global Database 藍/綠部署的其他許可
為 Aurora Global Database 叢集建立藍/綠部署時，除了上述許可之外，使用者還需要下列許可才能執行 操作來管理全域叢集拓撲。
建立藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:CreateGlobalCluster`
切換藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`
刪除藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:DeleteGlobalCluster`
# Amazon Aurora 藍/綠部署的限制和考量事項
若要在 Amazon RDS 中進行藍/綠部署，需要仔細考量複寫槽、資源管理、執行個體大小，以及對資料庫效能的潛在影響等因素。以下各節提供指引，協助您最佳化部署策略，以確保資料庫環境的最短停機時間、無縫轉換和有效管理。
**Topics**
+ [藍/綠部署的限制](#blue-green-deployments-limitations)
+ [藍/綠部署的 Aurora Global Database 限制](#blue-green-deployments-limitations-agd)
+ [藍/綠部署考量](#blue-green-deployments-consider)
## 藍/綠部署的限制
下列限制適用於藍/綠部署。
**Topics**
+ [藍/綠部署的一般限制](#blue-green-deployments-limitations-general)
+ [藍/綠部署的 Aurora MySQL 限制](#blue-green-deployments-limitations-mysql)
+ [Aurora PostgreSQL 藍/綠部署限制](#blue-green-deployments-limitations-postgres-logical)
### 藍/綠部署的一般限制
下列一般限制適用於藍/綠部署：
+ 您無法停止和啟動屬於藍/綠部署一部分的叢集。
+ 藍/綠部署不支援使用 AWS Secrets Manager管理主要使用者密碼。
+ 如果您嘗試在藍色資料庫叢集強制執行恢復，則藍/綠部署會中斷，而轉換會遭到封鎖。
+ 在切換期間，藍色和綠色環境無法與 Amazon Redshift 進行零 ETL 整合。您必須先刪除整合再進行切換，然後重新建立整合。
+ 建立藍/綠部署時，必須在綠色環境上停用事件排程器 (`event_scheduler` 參數)。這樣可以防止在綠色環境中產生事件並導致不一致。
+ 在藍色資料庫叢集設定的自動擴展政策不會複製到綠色環境。您必須在轉換後進行重新設定，無論這些政策最初是在藍色或綠色環境中設定。
+ 您無法將未加密的資料庫叢集變更為加密的資料庫叢集。此外，您無法將加密的資料庫叢集變更為未加密的資料庫叢集。
+ 您無法將藍色資料庫叢集變更為高於其對應綠色資料庫叢集的引擎版本。
+ 藍色環境和綠色環境中的資源必須在同一 AWS 帳戶中。
+ 下列功能不支援藍/綠部署：
+ Amazon RDS Proxy
+ 跨區域僅供讀取複本
+ Aurora Serverless v1 資料庫叢集
+ CloudFormation
### 藍/綠部署的 Aurora MySQL 限制
下列限制適用於 Aurora MySQL 藍/綠部署：
+ 來源資料庫叢集不能包含任何名為 `tmp` 的資料庫。具有此名稱的資料庫不會複製到綠色環境。
+ 藍色資料庫叢集不能是外部 binlog 複本。
+ 如果是已啟用恢復的來源資料庫叢集，則會在沒有恢復支援的情況下建立綠色資料庫叢集。這是因為恢復不適用於二進位日誌 (binlog) 複寫，但藍/綠部署需要此功能。如需詳細資訊，請參閱[恢復 Aurora 資料庫叢集](AuroraMySQL.Managing.Backtrack.md)。
+ 藍/綠部署不支援 AWS JDBC Driver for MySQL。如需詳細資訊，請參閱在 GitHub 的[已知限制](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)。
### Aurora PostgreSQL 藍/綠部署限制
下列限制適用於 Aurora PostgreSQL 藍/綠部署 ()。。
+ 除非在藍色資料庫叢集上將 `rds.logically_replicate_unlogged_tables` 參數設定為 `1`，否則不會將[未記錄的](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED)資料表複寫到綠色環境。在建立藍/綠部署之後不要修改此參數值，以避免可能在未記錄的資料表發生複寫錯誤。
+ 藍色資料庫叢集不能是邏輯來源 (發布者) 或複本 (訂閱用戶)。
+ 如果藍色資料庫叢集設定為外部資料包裝函式 (FDW) 延伸模組的外部伺服器，您必須使用叢集端點名稱，而非 IP 位址。這可讓組態在轉換之後保持運作狀態。
+ 在藍/綠部署中，每個資料庫都需要邏輯複寫槽。隨著資料庫數量的增加，資源負荷會增加，並可能導致複寫延遲，特別是當資料庫叢集未充分擴展時。此影響取決於資料庫工作負載和連線數量等因素。若要緩解此問題，請考慮擴展資料庫執行個體類別，或減少來源叢集的資料庫數目。
+ 針對 15.7 版和更新的 15 版，以及 16.3 版和更新的 16 版，僅支援Babelfish for Aurora PostgreSQL 的藍/綠部署。
+ 如果想要在 Aurora 複本中擷取執行計劃，您必須在呼叫 `apg_plan_mgmt.create_replica_plan_capture` 函數時提供藍色資料庫叢集端點。這可確保計劃擷取在轉換之後繼續運作。如需詳細資訊，請參閱[擷取複本中的 Aurora PostgreSQL 執行計畫](AuroraPostgreSQL.QPM.Plancapturereplicas.md)。
+ 在綠色環境中邏輯複寫[套用程序](https://www.postgresql.org/docs/current/logical-replication-architecture.html)為單執行緒。如果藍色環境產生大量寫入流量，則綠色環境可能無法跟上進度。這可能會導致複寫延遲或失敗，對於產生持續高寫入輸送量的工作負載尤其如此。請務必徹底測試工作負載。對於需要主要版本升級和處理大量寫入工作負載的案例，請考慮使用 [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) 或[自我管理邏輯複寫](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html)等替代方法。
+ 在 Aurora 的藍/綠部署期間，不支援在分割資料表建立新的分割區。建立新的分割區涉及資料定義語言 (DDL) 操作 (例如 `CREATE TABLE`)，系統不會將這些操作從藍色環境複寫到綠色環境。不過，系統會將現有的分割資料表及其資料複寫至綠色環境。
+ 下列限制適用於 PostgreSQL 延伸模組：
+ 建立藍/綠部署時，必須在藍色環境中停用 `pg_partman` 延伸模組。延伸模組會執行 DDL 作業 (例如 `CREATE TABLE`)，其會中斷從藍色環境到綠色環境的邏輯複寫。
+ 建立藍/綠部署之後，所有綠色資料庫上的 `pg_cron` 延伸模組必須保持停用狀態。延伸模組具有以超級使用者身分執行的背景工作者，且會略過綠色環境的唯讀設定，這可能會造成複寫衝突。
+ `apg_plan_mgmt` 延伸模組必須在所有綠色資料庫上將 `apg_plan_mgmt.capture_plan_baselines` 參數設定為 `off`，以避免在藍色環境中擷取相同的計劃時，發生主索引鍵衝突。如需詳細資訊，請參閱[Aurora PostgreSQL 查詢計劃管理的概觀](AuroraPostgreSQL.Optimize.overview.md)。
+ 建立藍/綠部署時，必須在藍色環境上停用 `pglogical` 和 `pgactive` 延伸模組。將綠色環境切換為新的生產環境之後，您可以再次啟用延伸模組。此外，藍色資料庫不能是外部執行個體的邏輯訂閱者。
+ 如果您使用的是 `pgAudit` 延伸模組，其必須保留在藍色和綠色資料庫執行個體的自訂資料庫參數群組上的共用程式庫 (`shared_preload_libraries`) 中。如需詳細資訊，請參閱[設定 pgAudit 擴充功能](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)。
#### 藍/綠部署的邏輯複寫特定限制
PostgreSQL 具有某些與邏輯複寫相關的限制，其會在針對 Aurora PostgreSQL 資料庫叢集建立藍/綠部署時轉換為限制。
下表描述適用於 Aurora PostgreSQL 藍/綠部署的邏輯複寫限制。如需詳細資訊，請參閱 PostgreSQL 邏輯複寫文件中的[限制](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。
| 限制 | 說明 |
| --- | --- |
| 資料定義語言 (DDL) 陳述式 (例如 CREATE TABLE 和 CREATE SCHEMA) 不會從藍色環境複寫到綠色環境。 | 如果 Aurora 在藍色環境中偵測到 DDL 變更，則您的綠色資料庫會進入**複寫降級**狀態。您必須刪除藍/綠部署和所有綠色資料庫，然後重新建立該部署。 |
| 系統不會將資料控制語言 (DCL) 陳述式 (例如 GRANT 和 REVOKE) 從藍色環境複寫到綠色環境。 | 如果 Aurora 偵測到有人嘗試在藍色環境中執行 DCL 陳述式，您將看到警告訊息。沒有可供變更此行為的組態或 API，因為其是藍/綠部署程序的限制。 |
| 序列物件上的 NEXTVAL 作業不會在藍色環境與綠色環境之間同步。 | 在轉換期間，Aurora 會在綠色環境中遞增序列值，以符合藍色環境中的序列值。如果您有數千個序列，這可能會延遲轉換。 |
| 藍色環境中的大型物件不會複寫到綠色環境。這包括現有的大型物件，以及藍/綠部署程序期間任何新建或修改的大型物件。 | 如果 Aurora 在藍色環境中偵測到 `pg_largeobject` 系統資料表中儲存的大型物件建立或修改，則您的綠色資料庫將進入**複寫降級**狀態。您必須刪除藍/綠部署和所有綠色資料庫，然後重新建立該部署。 |
| 重新整理具體化視觀表會中斷複寫。 | 在藍色環境中重新整理具體化視觀表會中斷在綠色環境中的複寫。避免在藍色環境中重新整理具體化視觀表。轉換後，您可以使用 [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 命令手動重新整理，或安排重新整理。 |
| 不允許在沒有主索引鍵的資料表上執行 UPDATE 和 DELETE 作業。 | 在建立藍/綠部署之前，請確定所有資料表都有主索引鍵或使用 `REPLICA IDENTITY FULL`。不過，只有在不存在主索引鍵或唯一索引鍵時才能使用 `REPLICA IDENTITY FULL`，因為其會影響複寫效能。如需詳細資訊，請參閱 [PostgreSQL 文件](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。 |
## 藍/綠部署的 Aurora Global Database 限制
除了上述一般和引擎特定限制之外，下列限制適用於 Aurora Global Database 的藍/綠部署：
+ 所有操作都必須從與全球資料庫寫入器叢集相同的區域啟動。
+ 執行全域切換或全域容錯移轉會導致作用中的藍/綠部署失效。藍綠部署需要從新的主要區域刪除並重新建立。
+ 對於 Aurora PostgreSQL，如果您已在生產環境中啟用全域寫入轉送並建立藍/綠部署，則會在綠色叢集上停用寫入轉送。只有在綠色環境成為新的生產環境時，才會在藍/綠切換之後，才會在綠色環境中啟用。切換後，會在`-old1`叢集上停用寫入轉送。
+ 在建立藍/綠部署之後修改全域資料庫的拓撲，會導致作用中的藍/綠部署失效。藍綠部署必須從新的主要區域刪除並重新建立。
+ 自動化快照會根據最初在舊藍色環境中設定的備份保留天數進行保留。舊藍叢集的自動快照不會複製到綠色。
+ 在藍/綠轉換期間支援全域容錯移轉，但在藍/綠轉換期間不支援全域轉換。
+ 確保綠色環境的資料庫叢集和資料庫參數群組存在於名稱相同的所有次要區域中。如果任何區域中的參數群組無法使用，則會使用區域中的預設參數群組。
+ 在藍/綠部署切換期間，避免在任何全域資料庫成員上使用 RDS Proxy。
## 藍/綠部署考量
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 呼叫](logging-using-cloudtrail.md)。
+ 如果您針對藍色環境中的資源使用資料庫活動串流，請調整您的應用程式，以在切換後監控新串流的資料庫事件。如需詳細資訊，請參閱[資料庫活動串流的支援區域和 Aurora 資料庫引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md)。
+ 如果您使用 Performance Insights API，請在切換後調整 API 呼叫中的資源 ID。如需詳細資訊，請參閱[在 Amazon Aurora 上使用績效詳情監控資料庫負載](USER_PerfInsights.md)。
您可以在切換後監控具有相同名稱的資料庫，但其不包含切換前的資料。
+ 如果您在 IAM 政策中使用資源 ID，請務必在必要時新增新轉換資源的資源 ID。如需詳細資訊，請參閱[Amazon Aurora 的 Identity and access management](UsingWithRDS.IAM.md)。
+ 如果您有與資料庫叢集相關聯的 IAM 角色，請務必在轉換後重新建立關聯。連接的角色不會自動複製到綠色環境。
+ 如果您使用 [IAM 資料庫身份驗證](UsingWithRDS.IAMDBAuth.md)對資料庫叢集進行身分驗證，請確定用於資料庫存取的 IAM 政策同時具有政策 `Resource` 元素下方列出的藍色和綠色資料庫。這是必要的，以便在切換後連線到綠色資料庫。如需詳細資訊，請參閱[建立並使用 IAM 政策進行 IAM 資料庫存取](UsingWithRDS.IAMDBAuth.IAMPolicy.md)。
+ 如果您想要還原屬於藍/綠部署之資料庫叢集的手動資料庫叢集快照，請確定透過檢查取得快照的時間來還原正確的資料庫叢集快照。如需詳細資訊，請參閱[從資料庫叢集快照還原](aurora-restore-snapshot.md)。
+ 切換後，由於藍色環境的檢查點在綠色環境中無效，因此 AWS Database Migration Service (AWS DMS) 複寫任務無法繼續。您必須使用新檢查點重新建立 DMS 任務，才能繼續複寫。
+ Amazon Aurora 在藍色環境中*複製*基礎 Aurora 儲存磁碟區，進而建立綠色環境。綠色叢集磁碟區只會儲存對綠色環境所做的增量變更。若您刪除藍色環境中的資料庫叢集，綠色環境中的基礎 Aurora 儲存磁碟區大小會增加到完整大小。如需詳細資訊，請參閱[複製 Amazon Aurora 資料庫叢集的一個磁碟區](Aurora.Managing.Clone.md)。
+ 若您在藍/綠部署的綠色環境中將資料庫執行個體新增至資料庫叢集，則在切換時，新的資料庫執行個體不會取代藍色環境中的資料庫執行個體。不過，新的資料庫執行個體會保留在資料庫叢集中，並在新的生產環境中成為資料庫執行個體。
+ 在藍/綠部署的綠色環境中刪除資料庫叢集中的資料庫執行個體時，您無法建立新的資料庫執行個體，以在藍/綠部署中取代該執行個體。
如果您使用與所刪除資料庫執行個體相同的名稱和 ARN 建立的新資料庫執行個體，則它具有不同的 `DbiResourceId`，因此不屬於綠色環境。
如果您在綠色環境中刪除資料庫叢集中的資料庫執行個體，則會產生下列行為：
+ 如果藍色環境中存在名稱相同的資料庫執行個體，則它不會切換至綠色環境中的資料庫執行個體。此資料庫執行個體不會透過將 `-oldn` 附加至資料庫執行個體名稱來重新命名。
+ 指向藍色環境中資料庫執行個體的任何應用程式都會在切換後繼續使用相同的資料庫執行個體。
+ 如果您使用資源標籤進行存取控制或操作管理，則需要了解在切換之前，藍色和綠色環境之間不會同步標籤變更。當您建立藍/綠部署時，藍環境的標籤會複製到綠色環境。建立之後，您對任一環境所做的任何標籤修改都不會自動同步。在切換期間，藍色環境標籤會取代綠色環境中的所有標籤。在建立藍/綠部署之前，請將所有必要的標籤套用至藍環境，或在切換後將必要的標籤重新套用至新的生產環境。如需標籤的詳細資訊，請參閱[標記 Amazon Aurora 和 Amazon RDS 資源](USER_Tagging.md)。
# Amazon Aurora 藍/綠部署的最佳實務
下列是藍/綠部署的最佳實務。
**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)
## 藍/綠部署的一般最佳實務
建立藍/綠部署時，請考慮下列一般最佳實務。
+ 切換前，請在綠色環境中徹底測試 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 藍/綠部署最佳實務
當您從 Aurora MySQL 資料庫叢集建立藍/綠部署時，請考慮下列最佳實務。
+ 如果綠色環境遇到複本延遲，請考慮下列事項：
+ 如果不需要，請停用二進位日誌保留，或暫時停用，直到複寫趕上進度為止。若要這樣做，請將 `binlog_format` 資料庫叢集參數設回 `0`，然後重新啟動綠色寫入器資料庫執行個體。
+ 暫時在綠色資料庫參數群組中將 `innodb_flush_log_at_trx_commit` 參數設為 `0`。在複寫趕上進度後，在轉換之前還原為預設值 `1`。如果使用暫時參數值時發生非預期的關機或當機，請重建綠色環境，以避免未偵測到的資料損毀。如需詳細資訊，請參閱 [設定日誌緩衝區的排清頻率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。
## Aurora PostgreSQL 藍/綠部署的最佳實務
當您從 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`。否則，複寫系統會傳播變更與執行觸發條件，而會導致複寫。
+ 長時間執行的交易可能會導致嚴重的複本延遲。若要縮短複本延遲，請考慮執行下列動作：
+ 減少長時間執行的交易和子交易，這些交易可能會延遲，直到綠色環境趕上藍色環境為止。
+ 減少藍色環境的大量操作，直到綠色環境趕上藍色環境為止。
+ 在建立藍/綠部署之前，對忙碌資料表啟動手動清空凍結操作。如需說明，請參閱[執行手動清空凍結](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\$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 全域資料庫藍/綠部署最佳實務
除了上述一般和引擎特定最佳實務之外，請考慮 Aurora Global Database 的最佳實務。
+ 監控下列 CloudWatch 指標，以識別生產環境中活動量低的期間：
+ `DatabaseConnections`
+ `ActiveTransactions`
在計劃的維護時段或活動量低的期間，安排藍/綠轉換。
+ 藍/綠轉換持續時間取決於您的工作負載和次要區域的數量。當您啟動藍/綠切換時，服務會等待複本延遲達到零，然後再繼續。我們建議您在開始切換之前檢查複本延遲。
+ 如果您想要使用綠色環境預設參數以外的資料庫參數或資料庫叢集參數群組，請先在所有次要區域中建立名稱相同的所需參數群組，再啟動藍/綠部署。