

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

# 使用 Amazon Aurora 藍/綠部署進行資料庫更新
<a name="blue-green-deployments"></a>

藍/綠部署會將生產資料庫環境複製到個別已同步的預備環境。透過使用 Amazon Aurora 藍/綠部署，您可以在預備環境中對資料庫進行變更，而不會影響生產環境。例如，您可以升級主要或次要資料庫引擎版本，或在預備環境中變更資料庫參數。備妥後，您可以將預備環境提升為新的生產資料庫環境，停機時間通常不到一分鐘。

Amazon Aurora 在生產環境中*複製*基礎 Aurora 儲存磁碟區，進而建立預備環境。預備環境中的叢集磁碟區只會存放對該環境所做的增量變更。

**注意**  
目前，Aurora MySQL、Aurora PostgreSQL 和 Aurora Global Database。如需了解 Amazon RDS 引擎可用性，請參閱《Amazon RDS 使用者指南》**中的[使用 Amazon RDS 藍/綠部署進行資料庫更新](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)。

**Topics**
+ [Amazon Aurora 藍/綠部署概觀](blue-green-deployments-overview.md)
+ [在 Amazon Aurora 中建立藍/綠部署](blue-green-deployments-creating.md)
+ [在 Amazon Aurora 中檢視藍/綠部署](blue-green-deployments-viewing.md)
+ [在 Amazon Aurora 中切換藍/綠部署](blue-green-deployments-switching.md)
+ [刪除 Amazon Aurora 中的藍/綠部署](blue-green-deployments-deleting.md)

# Amazon Aurora 藍/綠部署概觀
<a name="blue-green-deployments-overview"></a>

透過使用 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)

## 區域和版本可用性
<a name="blue-green-deployments-region-version-availability"></a>

功能可用性和支援會因每個資料庫引擎的特定版本以及 AWS 區域而有所不同。如需詳細資訊，請參閱[藍/綠部署支援的區域和 Aurora 資料庫引擎](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md)。

## 使用 Amazon RDS 藍/綠部署的優點
<a name="blue-green-deployments-benefits"></a>

透過使用 Amazon RDS 藍/綠部署，您可以隨時掌握最新的安全修補程式、改善資料庫效能，以及採用較新的資料庫功能，其停機時間短暫且可預測。藍/綠部署可減少資料庫更新 (例如主要或次要引擎版本升級) 的風險和停機時間。

藍/綠部署提供下列優點：
+ 輕鬆建立生產就緒的預備環境。
+ 自動將資料庫變更從生產環境複寫到預備環境。
+ 在安全預備環境中測試資料庫變更，而不會影響生產環境。
+ 隨時掌握最新的資料庫修補程式和系統更新。
+ 實作和測試較新的資料庫功能。
+ 切換預備環境以成為新的生產環境，而無需對應用程式進行變更。
+ 透過使用內建的防護機制安全切換。
+ 消除切換期間的資料遺失情況。
+ 通常在一分鐘內快速切換，取決於您的工作負載。

## 藍/綠部署的工作流程
<a name="blue-green-deployments-major-steps"></a>

當您使用藍/綠部署進行 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 藍/綠部署操作的存取權
<a name="blue-green-deployments-authorizing-access"></a>

使用者必須具有必要的許可，才能執行與藍/綠部署相關的操作。您可以建立 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 藍/綠部署的其他許可
<a name="blue-green-deployments-authorization-global"></a>

 為 Aurora Global Database 叢集建立藍/綠部署時，除了上述許可之外，使用者還需要下列許可才能執行 操作來管理全域叢集拓撲。

建立藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:CreateGlobalCluster`

切換藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:ModifyGlobalCluster`
+ `rds:PromoteReadReplicaDBCluster`

刪除藍/綠部署的使用者必須具有執行下列 RDS 操作的許可：
+ `rds:DeleteGlobalCluster`

# Amazon Aurora 藍/綠部署的限制和考量事項
<a name="blue-green-deployments-considerations"></a>

若要在 Amazon RDS 中進行藍/綠部署，需要仔細考量複寫槽、資源管理、執行個體大小，以及對資料庫效能的潛在影響等因素。以下各節提供指引，協助您最佳化部署策略，以確保資料庫環境的最短停機時間、無縫轉換和有效管理。

**Topics**
+ [藍/綠部署的限制](#blue-green-deployments-limitations)
+ [藍/綠部署的 Aurora Global Database 限制](#blue-green-deployments-limitations-agd)
+ [藍/綠部署考量](#blue-green-deployments-consider)

## 藍/綠部署的限制
<a name="blue-green-deployments-limitations"></a>

下列限制適用於藍/綠部署。

**Topics**
+ [藍/綠部署的一般限制](#blue-green-deployments-limitations-general)
+ [藍/綠部署的 Aurora MySQL 限制](#blue-green-deployments-limitations-mysql)
+ [Aurora PostgreSQL 藍/綠部署限制](#blue-green-deployments-limitations-postgres-logical)

### 藍/綠部署的一般限制
<a name="blue-green-deployments-limitations-general"></a>

下列一般限制適用於藍/綠部署：
+ 您無法停止和啟動屬於藍/綠部署一部分的叢集。
+ 藍/綠部署不支援使用 AWS Secrets Manager管理主要使用者密碼。
+ 如果您嘗試在藍色資料庫叢集強制執行恢復，則藍/綠部署會中斷，而轉換會遭到封鎖。
+ 在切換期間，藍色和綠色環境無法與 Amazon Redshift 進行零 ETL 整合。您必須先刪除整合再進行切換，然後重新建立整合。
+ 建立藍/綠部署時，必須在綠色環境上停用事件排程器 (`event_scheduler` 參數)。這樣可以防止在綠色環境中產生事件並導致不一致。
+ 在藍色資料庫叢集設定的自動擴展政策不會複製到綠色環境。您必須在轉換後進行重新設定，無論這些政策最初是在藍色或綠色環境中設定。
+ 您無法將未加密的資料庫叢集變更為加密的資料庫叢集。此外，您無法將加密的資料庫叢集變更為未加密的資料庫叢集。
+ 您無法將藍色資料庫叢集變更為高於其對應綠色資料庫叢集的引擎版本。
+ 藍色環境和綠色環境中的資源必須在同一 AWS 帳戶中。
+ 下列功能不支援藍/綠部署：
  + Amazon RDS Proxy
  + 跨區域僅供讀取複本
  + Aurora Serverless v1 資料庫叢集
  + CloudFormation

### 藍/綠部署的 Aurora MySQL 限制
<a name="blue-green-deployments-limitations-mysql"></a>

下列限制適用於 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 藍/綠部署限制
<a name="blue-green-deployments-limitations-postgres-logical"></a>

下列限制適用於 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)。

#### 藍/綠部署的邏輯複寫特定限制
<a name="blue-green-deployments-limitations-postgres"></a>

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 限制
<a name="blue-green-deployments-limitations-agd"></a>

除了上述一般和引擎特定限制之外，下列限制適用於 Aurora Global Database 的藍/綠部署：
+ 所有操作都必須從與全球資料庫寫入器叢集相同的區域啟動。
+ 執行全域切換或全域容錯移轉會導致作用中的藍/綠部署失效。藍綠部署需要從新的主要區域刪除並重新建立。
+ 對於 Aurora PostgreSQL，如果您已在生產環境中啟用全域寫入轉送並建立藍/綠部署，則會在綠色叢集上停用寫入轉送。只有在綠色環境成為新的生產環境時，才會在藍/綠切換之後，才會在綠色環境中啟用。切換後，會在`-old1`叢集上停用寫入轉送。
+ 在建立藍/綠部署之後修改全域資料庫的拓撲，會導致作用中的藍/綠部署失效。藍綠部署必須從新的主要區域刪除並重新建立。
+ 自動化快照會根據最初在舊藍色環境中設定的備份保留天數進行保留。舊藍叢集的自動快照不會複製到綠色。
+ 在藍/綠轉換期間支援全域容錯移轉，但在藍/綠轉換期間不支援全域轉換。
+ 確保綠色環境的資料庫叢集和資料庫參數群組存在於名稱相同的所有次要區域中。如果任何區域中的參數群組無法使用，則會使用區域中的預設參數群組。
+ 在藍/綠部署切換期間，避免在任何全域資料庫成員上使用 RDS Proxy。

## 藍/綠部署考量
<a name="blue-green-deployments-consider"></a>

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 藍/綠部署的最佳實務
<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\$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 全域資料庫藍/綠部署最佳實務
<a name="blue-green-deployments-best-practices-agd"></a>

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

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

# 在 Amazon Aurora 中建立藍/綠部署
<a name="blue-green-deployments-creating"></a>

RDS 將藍色環境的拓撲和功能複製到預備區域。當藍色資料庫執行個體具有僅供讀取複本時，系統會將僅供讀取複本複製為綠色執行個體的複本。所有綠色複本的分配儲存符合綠色主要執行個體，而其他儲存參數則繼承自藍色複本。

建立藍/綠部署時，您可以指定要在部署中複製的資料庫叢集。您選擇的資料庫叢集是生產資料庫叢集，而且其會成為藍色環境中的資料庫叢集。RDS 將藍色環境的拓撲複製到預備區域，以及複製其設定的功能。資料庫叢集會複製到綠色環境，而且 RDS 會設定從藍色環境中的資料庫叢集複寫到綠色環境中的資料庫叢集。RDS 也會複製資料庫叢集中的所有資料庫執行個體。

**Topics**
+ [準備進行藍/綠部署](#blue-green-deployments-creating-preparing)
+ [在建立藍/綠部署時指定變更](#blue-green-deployments-creating-changes)
+ [建立藍/綠部署](#blue-green-deployments-creating-create)
+ [建立藍/綠部署的設定](#create-blue-green-settings)

## 準備進行藍/綠部署
<a name="blue-green-deployments-creating-preparing"></a>

根據 Aurora 資料庫叢集所執行的引擎而定，建立藍/綠部署之前，您必須執行某些步驟。

**Topics**
+ [準備 Aurora MySQL 資料庫叢集以進行藍/綠部署](#blue-green-deployments-creating-preparing-mysql)
+ [準備 Aurora PostgreSQL 資料庫叢集以進行藍/綠部署](#blue-green-deployments-creating-preparing-postgres)
+ [準備 Aurora 全域資料庫資料庫叢集以進行藍/綠部署](#blue-green-deployments-creating-preparing-agd)

### 準備 Aurora MySQL 資料庫叢集以進行藍/綠部署
<a name="blue-green-deployments-creating-preparing-mysql"></a>

在針對 Aurora MySQL 資料庫叢集建立藍/綠部署之前，叢集必須與已開啟[二進位記錄](USER_LogAccess.MySQL.BinaryFormat.md) (`binlog_format`) 的自訂資料庫叢集參數群組相關聯。從藍色環境複寫到綠色環境時，需要二進位記錄。雖然任何 binlog 格式都可以運作，但我們建議 `ROW`，以降低複寫不一致的風險。如需建立自訂資料庫叢集參數群組和設定參數的相關資訊，請參閱 [Amazon Aurora 資料庫叢集的資料庫叢集參數群組](USER_WorkingWithDBClusterParamGroups.md)。

**注意**  
啟用二進位日誌記錄會增加資料庫叢集的寫入磁碟 I/O 操作次數。您可以使用 `VolumeWriteIOPs` CloudWatch 指標來監控 IOPS 使用情況。

啟用二進位記錄之後，請務必重新啟動資料庫叢集，以讓變更生效。藍/綠部署*要求*寫入器執行個體與資料庫叢集參數群組同步，否則建立作業將會失敗。如需詳細資訊，請參閱[在 Aurora 叢集中重新啟動資料庫執行個體](aurora-reboot-db-instance.md)。

此外，我們建議將二進位日誌保留期變更為 `NULL` 以外的值，以防止二進位日誌檔案遭到清除。如需詳細資訊，請參閱[設定和顯示二進位日誌組態](mysql-stored-proc-configuring.md)。

### 準備 Aurora PostgreSQL 資料庫叢集以進行藍/綠部署
<a name="blue-green-deployments-creating-preparing-postgres"></a>

在針對 Aurora PostgreSQL 資料庫叢集建立藍/綠部署之前，請務必執行下列動作。
+ 將叢集與已啟用邏輯複寫 (`rds.logical_replication`) 的自訂資料庫叢集參數群組建立關聯。從藍色環境複寫到綠色環境時，需要邏輯複寫。

  啟用邏輯複寫時，您也需要調校特定叢集參數，例如 `max_replication_slots`、`max_logical_replication_workers` 和 `max_worker_processes`。如需啟用邏輯複寫和調校這些參數的指示，請參閱[針對 Aurora PostgreSQL 資料庫叢集設定邏輯複寫](AuroraPostgreSQL.Replication.Logical.Configure.md)。

  此外，請確保將 `synchronous_commit` 參數設為 `on`。

  設定必要的參數之後，請重新啟動資料庫叢集，讓變更生效。藍/綠部署*要求*寫入器執行個體與資料庫叢集參數群組同步，否則建立作業將會失敗。如需詳細資訊，請參閱[在 Aurora 叢集中重新啟動資料庫執行個體](aurora-reboot-db-instance.md)。
+ 確定資料庫叢集執行的是與藍/綠部署相容的 Aurora PostgreSQL 版本。如需相容版本的清單，請參閱 [透過 Aurora PostgreSQL 進行藍/綠部署](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.apg)。
+ 請確定資料庫叢集中的所有資料表都有主索引鍵。PostgreSQL 邏輯複寫不允許對沒有主索引鍵的資料表進行 UPDATE 或 DELETE 操作。

### 準備 Aurora 全域資料庫資料庫叢集以進行藍/綠部署
<a name="blue-green-deployments-creating-preparing-agd"></a>

為您的 Aurora Global Database 資料庫叢集建立藍/綠部署之前，請注意下列幾點：
+ 所有操作都必須從與全球資料庫寫入器叢集相同的區域啟動。
+ 參數群組組態：
  + 綠色環境會使用您指定的新參數群組，或與藍色叢集相同的參數群組 （預設）。
  + 自訂參數群組會複製到綠色環境。
  + 如果指定的參數群組不存在於次要區域中，則次要區域中的預設參數群組會用於綠色環境。

## 在建立藍/綠部署時指定變更
<a name="blue-green-deployments-creating-changes"></a>

建立藍/綠部署時，您可以在綠色環境中對資料庫叢集進行下列變更。

您可以在部署之後，於綠色環境中對資料庫叢集及其資料庫執行個體進行其他修改。例如，您可以指定較高的引擎版本或不同的參數群組。

如需修改資料庫叢集的詳細資訊，請參閱 [修改 Amazon Aurora 資料庫叢集](Aurora.Modifying.md)。

**Topics**
+ [指定較高的引擎版本](#blue-green-deployments-engine-version)
+ [指定不同的資料庫參數群組](#blue-green-deployments-parameters)

### 指定較高的引擎版本
<a name="blue-green-deployments-engine-version"></a>

如果想要測試資料庫引擎升級，您可以指定更高的引擎版本。轉換時，資料庫會升級至您指定的主要或次要資料庫引擎版本。

### 指定不同的資料庫參數群組
<a name="blue-green-deployments-parameters"></a>

指定資料庫叢集參數群組，需與資料庫叢集所使用的資料庫叢集參數群組不同。您可以測試參數變更如何影響綠色環境中的資料庫叢集，或在升級時針對新的主要資料庫引擎版本指定參數群組。

如果您指定不同的資料庫叢集參數群組，則指定的參數群組會與綠色環境中的資料庫叢集相關聯。如果您未指定不同的資料庫叢集參數群組，則綠色環境中的資料庫叢集會與藍色資料庫叢集相同的參數群組相關聯。

## 建立藍/綠部署
<a name="blue-green-deployments-creating-create"></a>

您可以使用 AWS 管理主控台、 AWS CLI或 RDS API 建立藍/綠部署。

### 主控台
<a name="blue-green-deployments-creating-console"></a>

**建立藍/綠部署**

1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。

1. 在導覽窗格中，選擇 **Databases** (資料庫)，然後選擇您要將其複製到綠色環境的資料庫叢集。

1. 選擇**動作**、**建立藍/綠部署**。

   **建立藍/綠部署**頁面即會出現。  
![\[建立藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-create-aurora.png)

1. 檢閱藍色資料庫識別符。確定其符合您在藍色環境中預期的資料庫執行個體。如果不符，請選擇 **Cancel** (取消)。

1. 針對**藍/綠部署名稱**，輸入藍/綠部署的名稱。

1. 在其餘區段中，指定綠色環境的設定。如需每項設定的相關資訊，請參閱 [建立藍/綠部署的設定](#create-blue-green-settings)。

   您可以在部署之後，於綠色環境中對資料庫進行其他修改。

1. 選擇**建立**。

### AWS CLI
<a name="blue-green-deployments-creating-cli"></a>

若要使用 建立藍/綠部署 AWS CLI，請使用 [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html) 命令。如需所有可用選項的資訊，請參閱 [建立藍/綠部署的設定](#create-blue-green-settings)。

**Example**  
針對 Linux、macOS 或 Unix：  

```
aws rds create-blue-green-deployment \
    --blue-green-deployment-name aurora-blue-green-deployment \
    --source arn:aws:rds:us-east-2:123456789012:cluster:auroradb \
    --target-engine-version 8.0 \
    --target-db-cluster-parameter-group-name mydbclusterparametergroup
```
在 Windows 中：  

```
aws rds create-blue-green-deployment ^
    --blue-green-deployment-name aurora-blue-green-deployment ^
    --source arn:aws:rds:us-east-2:123456789012:cluster:auroradb ^
    --target-engine-version 8.0 ^
    --target-db-cluster-parameter-group-name mydbclusterparametergroup
```

### RDS API
<a name="blue-green-deployments-creating-api"></a>

若要使用 Amazon RDS API 建立藍/綠部署，請使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html) 操作。如需每個選項的詳細資訊，請參閱[建立藍/綠部署的設定](#create-blue-green-settings)。

## 建立藍/綠部署的設定
<a name="create-blue-green-settings"></a>

下表說明您在建立藍/綠部署時可以選擇的設定。如需 AWS CLI 選項的詳細資訊，請參閱 [create-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/create-blue-green-deployment.html)。如需 RDS API 參數的詳細資訊，請參閱 [CreateBlueGreenDeployment](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateBlueGreenDeployment.html)。


| 主控台設定 | 設定說明 | CLI 選項和 RDS API 參數 | 
| --- | --- | --- | 
|  **藍/綠部署識別符**  |  藍/綠部署的名稱。  |  **CLI 選項：** `--blue-green-deployment-name` **API 參數：**  `BlueGreenDeploymentName`  | 
| 藍色資料庫識別符 |  您想要複製到綠色環境之叢集的識別符。使用 CLI 或 API 時，請指定叢集 Amazon Resource Name (ARN)。  |  **CLI 選項：** `--source` **API 參數：** `Source`  | 
|  綠色資料庫的資料庫叢集參數群組  | 在綠色環境中要與資料庫相關聯的參數群組。 |  **CLI 選項：**  `--target-db-cluster-parameter-group-name` **API 參數：**  `TargetDBClusterParameterGroupName`  | 
|  **綠色資料庫的引擎版本**  |  將綠色環境中的資料庫叢集升級至指定的資料庫引擎版本。 如果您選擇 Aurora PostgreSQL 資料庫叢集，請檢閱並確認邏輯複寫限制。如需詳細資訊，請參閱[藍/綠部署的邏輯複寫特定限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。  |  **CLI 選項：** `--target-engine-version` **RDS API 參數：** `TargetEngineVersion`  | 

# 在 Amazon Aurora 中檢視藍/綠部署
<a name="blue-green-deployments-viewing"></a>

您可以使用 AWS 管理主控台、AWS CLI 或 RDS API 檢視藍/綠部署的詳細資訊。

您也可以檢視和訂閱事件，以取得藍/綠部署的相關資訊。如需更多詳細資訊，請參閱 [藍/綠部署事件](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)。

## 主控台
<a name="blue-green-deployments-viewing-console"></a>

**檢視藍/綠部署的詳細資訊**

1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。

1. 在導覽窗格中，選擇 **Databases** (資料庫)，然後在清單中尋找藍/綠部署。  
![\[資料庫清單中的藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-db-list-aurora.png)

   藍/綠部署的 **Role** (角色) 值是 **Blue/Green Deployment** (藍/綠部署)。

1. 選擇您要檢視以顯示其詳細資訊的藍/綠部署名稱。

   每個索引標籤都有藍色部署的區段，以及綠色部署的區段。例如，在**組態**索引標籤上，如果您要升級綠色環境中的資料庫引擎版本，則資料庫引擎版本在藍色環境和綠色環境中可能會有所不同。

   下圖顯示**連線和安全**索引標籤的範例：  
![\[藍/綠部署詳細資訊\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-details-aurora.png)

   **連線與安全性**索引標籤也包含名為**複寫**的區段，其中顯示目前的複寫狀態，以及藍色環境與綠色環境之間的複本延遲。如果複寫狀態為 `Replicating`，則表示藍/綠部署成功複寫。

   對於 Aurora PostgreSQL 藍/綠部署 ()，如果您在藍色環境中進行不支援的 DDL 或大型物件變更，則複寫狀態可能會變更為 `Replication degraded`。如需更多詳細資訊，請參閱 [藍/綠部署的邏輯複寫特定限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

   下圖顯示**組態**索引標籤的範例：  
![\[藍/綠部署組態詳細資訊\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-config-aurora.png)

   下圖顯示**狀態**索引標籤的範例：  
![\[藍/綠部署狀態\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-view-status-aurora.png)

## AWS CLI
<a name="blue-green-deployments-viewing-cli"></a>

若要使用 AWS CLI 檢視藍/綠部署的詳細資訊，請使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令。

**Example 透過篩選藍/綠部署的名稱來檢視其詳細資訊**  
使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令時，您可以依 `--blue-green-deployment-name` 篩選。  
下列範例顯示藍/綠部署 (名為 `my-blue-green-deployment`) 的詳細資訊。  

```
aws rds describe-blue-green-deployments \
  --filters Name=blue-green-deployment-name,Values=my-blue-green-deployment
```

**Example 透過指定藍/綠部署的識別符來檢視其詳細資訊**  
使用 [describe-blue-green-deployments](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-blue-green-deployments.html) 命令時，您可以指定 `--blue-green-deployment-identifier` 選項。  
下列範例顯示識別符為 `bgd-1234567890abcdef` 的藍/綠部署的詳細資訊。  

```
aws rds describe-blue-green-deployments \
  --blue-green-deployment-identifier bgd-1234567890abcdef
```

## RDS API
<a name="blue-green-deployments-viewing-api"></a>

若要使用 Amazon RDS API 檢視藍/綠部署的詳細資訊，請使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeBlueGreenDeployments.html) 操作並指定 `BlueGreenDeploymentIdentifier`。

# 在 Amazon Aurora 中切換藍/綠部署
<a name="blue-green-deployments-switching"></a>

*轉換*會在綠色環境中將資料庫叢集 (包括其資料庫執行個體) 轉換為生產資料庫叢集。切換前，生產流量會路由到藍色環境中的叢集。切換後，生產流量會路由到綠色環境中的資料庫叢集。

*轉換*藍/綠部署與在藍/綠部署中*提升*綠色資料庫叢集不同。如果您透過從**動作**功能表中選擇**提升**，手動提升綠色資料庫叢集，則藍色和綠色環境之間的複寫會中斷，且藍/綠部署會進入**無效組態**的狀態。

**Topics**
+ [切換逾時](#blue-green-deployments-switching-timeout)
+ [切換防護機制](#blue-green-deployments-switching-guardrails)
+ [切換動作](#blue-green-deployments-switching-actions)
+ [切換最佳實務](#blue-green-deployments-switching-best-practices)
+ [在切換前驗證 CloudWatch 指標](#blue-green-deployments-switching-over-cloudwatch)
+ [轉換前監控複本延遲](#blue-green-deployments-monitor-replica-lag)
+ [切換藍/綠部署](#blue-green-deployments-switching-over)
+ [切換後](#blue-green-deployments-switching-after)

## 切換逾時
<a name="blue-green-deployments-switching-timeout"></a>

您可以指定介於 30 秒與 3,600 秒(一小時) 之間的切換逾時期間。如果切換所花費的時間超過指定的持續時間，則會復原任何變更，且不會對任一環境進行任何變更。預設逾時期間為 300 秒 (五分鐘)。

## 切換防護機制
<a name="blue-green-deployments-switching-guardrails"></a>

當您開始切換時，Amazon RDS 會執行一些基本檢查，以測試藍色和綠色環境是否準備好進行切換。這些檢查稱為*切換防護機制*。如果環境還沒有做好準備，這些切換防護機制可防止切換。因此，它們可避免超過預期的停機時間，並防止若切換開始，可能導致藍色和綠色環境之間遺失資料。

Amazon RDS 會在綠色環境上執行下列防護機制檢查：
+ **複寫運作狀態** – 檢查綠色資料庫叢集複寫狀態是否良好。綠色資料庫叢集是藍色資料庫叢集的複本。
+ **複寫延遲** – 檢查綠色資料庫叢集的複本延遲是否在轉換的允許限制內。允許的限制是以指定的逾時期間為基礎。複本延遲指出綠色資料庫叢集落後於其藍色資料庫叢集多遠。如需詳細資訊，請參閱[轉換前監控複本延遲](#blue-green-deployments-monitor-replica-lag)。
+ **作用中寫入** – 確定綠色資料庫叢集上沒有作用中寫入。

Amazon RDS 會在藍色環境上執行下列防護機制檢查：
+ **外部複寫**：對於 Aurora PostgreSQL，確保藍色環境不是自我管理的邏輯來源 (發布者) 或複本 (訂閱用戶)。若是如此，我們建議您捨棄藍色環境中所有資料庫的自我管理複寫槽和訂閱，繼續進行轉換，然後將其重新建立以繼續複寫。對於 Aurora MySQL，檢查藍色資料庫是否不是外部 binlog 複本。如果是，請確定其不是主動複寫。
+ **長時間執行的作用中寫入** – 確定藍色資料庫叢集上沒有長時間執行的作用中寫入，因為這些寫入可能會增加複本延遲。
+ **長時間執行的 DDL 陳述式** – 確定藍色資料庫叢集上沒有長時間執行的 DDL 陳述式，因為這些陳述式可能會增加複本延遲。
+ **不支援的 PostgreSQL 變更**：對於 Aurora PostgreSQL，請確定沒有任何 DDL 變更，也未在藍色環境執行大型物件的新增或修改。如需詳細資訊，請參閱[藍/綠部署的邏輯複寫特定限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

  如果 Amazon RDS 偵測到不支援的 PostgreSQL 變更，其會將複寫狀態變更為 `Replication degraded`，並通知您無法對藍/綠部署進行轉換。若要繼續進行轉換，建議您刪除並重新建立藍/綠部署和所有綠色資料庫。若要這樣做，請選擇**動作**、**刪除綠色資料庫**。

## 切換動作
<a name="blue-green-deployments-switching-actions"></a>

當您切換藍/綠部署時，RDS 會執行下列動作：

1. 執行防護機制檢查，以驗證藍色和綠色環境是否已準備好進行切換。

1. 在這兩個環境中停止資料庫叢集上的新寫入操作。

1. 捨棄與這兩個環境中資料庫執行個體的連線，而且不允許新的連線。

1. 等待複寫在綠色環境中趕上進度，以便綠色環境與藍色環境同步。

1. 在這兩個環境中重新命名資料庫叢集和資料庫執行個體。

   RDS 會重新命名綠色環境中的資料庫叢集和資料庫執行個體，以符合藍色環境中對應的資料庫叢集和資料庫執行個體。例如，假設藍色環境中資料庫執行個體的名稱為 `mydb`。也會假設綠色環境中對應資料庫執行個體的名稱為 `mydb-green-abc123`。在切換期間，綠色環境中資料庫執行個體的名稱會變更為 `mydb`。

   RDS 會重新命名藍色環境中的資料庫叢集和資料庫執行個體，方法是將 `-oldn` 附加至目前名稱 (其中 `n` 是數字)。例如，假設藍色環境中資料庫執行個體的名稱為 `mydb`。切換後，資料庫執行個體名稱可能是 `mydb-old1`。

   RDS 也會重新命名綠色環境中的端點，以符合藍色環境中的對應端點，以便不需要應用程式變更。

1. 允許連線至這兩個環境中的資料庫。

1. 在新的生產環境中允許資料庫叢集上的寫入操作。

   轉換後，之前的生產資料庫叢集只允許讀取操作。即使您在資料庫叢集上啟用寫入，其仍會保持唯讀狀態，直到您刪除藍/綠部署為止。

您可以使用 Amazon EventBridge 監控切換狀態。如需詳細資訊，請參閱[藍/綠部署事件](USER_Events.Messages.md#USER_Events.Messages.BlueGreenDeployments)。

在切換期間，藍色環境中的標籤會取代綠色環境中資源上的所有標籤。在此過程中，您直接新增至綠色環境資源的任何標籤都會遭到覆寫。如需標籤的詳細資訊，請參閱[標記 Amazon Aurora 和 Amazon RDS 資源](USER_Tagging.md)。

如果切換開始，然後在完成前由於任何原因而停止，則會復原任何變更，且不會對任一環境進行任何變更。

## 切換最佳實務
<a name="blue-green-deployments-switching-best-practices"></a>

在您轉換之前，我們強烈建議您完成下列任務，以遵守最佳實務：
+ 徹底測試綠色環境中的資源。確保它們正常有效地執行。
+ 監控相關 Amazon CloudWatch 指標。如需詳細資訊，請參閱[在切換前驗證 CloudWatch 指標](#blue-green-deployments-switching-over-cloudwatch)。
+ 識別切換的最佳時間。

  切換期間，會中斷這兩種環境中資料庫的寫入。識別生產環境上流量最低的時間。長時間執行的交易 (例如作用中 DDL) 可能會增加您的切換時間，因而延長生產工作負載的停機時間。

  如果您的資料庫叢集和資料庫執行個體上有大量連線，請考慮在切換藍/綠部署之前，手動將其減少到應用程式所需的最低數量。達成此目標的方法之一是建立一項指令碼，用以監控藍/綠部署狀態，並在偵測到狀態變更至 `SWITCHOVER_IN_PROGRESS` 時開始清除連線。
+ 確定這兩個環境中的資料庫叢集和資料庫執行個體處於 `Available` 狀態。
+ 確定綠色環境中的資料庫叢集運作良好且複寫中。
+ 請確定您的網路和用戶端組態不會將 DNS 快取存留時間 (TTL) 增加到五秒以上，這是 Aurora DNS 區域的預設值。否則，應用程式會在切換後繼續將寫入流量傳送至藍色環境。
+ 對於 Aurora PostgreSQL 藍/綠部署，請執行下列動作：
  + 檢閱邏輯複寫限制，並在轉換之前採取任何必要的動作。如需詳細資訊，請參閱[藍/綠部署的邏輯複寫特定限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。
  + 執行 `ANALYZE` 操作以重新整理 `pg_statistics` 資料表。這可降低轉換後發生效能問題的風險。
  + 啟動藍/綠部署切換之前，請確認您的應用程式不會覆寫工作階段層級的 `default_transaction_read_only` 參數。在切換期間，此參數會在綠色環境寫入器`on`上設定為 ，以防止寫入，直到提升完成為止。如果您的應用程式或交易將此組態覆寫為 `off`，您的應用程式可能會在切換過程中將資料寫入綠色環境。如果轉換必須轉返，藍色環境中無法使用這些寫入，要求您手動解決資料不一致的問題。我們強烈建議稽核您的應用程式查詢，以確保它們遵守`default_transaction_read_only`設定，然後再繼續切換。

**注意**  
切換期間，您無法修改切換中包含的任何資料庫叢集。

## 在切換前驗證 CloudWatch 指標
<a name="blue-green-deployments-switching-over-cloudwatch"></a>

轉換藍/綠部署之前，建議您檢查 Amazon CloudWatch 中下列指標的值。
+ `DatabaseConnections` – 使用此指標估計藍/綠部署的活動層級，並在切換前確認該值處於部署的可接受層級。如果績效詳情已開啟，則 `DBLoad` 為更準確的指標。
+ `ActiveTransactions` – 若在任何資料庫執行個體中，資料庫參數群組中的 `innodb_monitor_enable` 設為 `all`，請使用此指標來查看是否有大量作用中交易可能封鎖切換。

如需詳細資訊，請參閱[Amazon Aurora 的 Amazon CloudWatch 指標](Aurora.AuroraMonitoring.Metrics.md)。

## 轉換前監控複本延遲
<a name="blue-green-deployments-monitor-replica-lag"></a>

在轉換藍/綠部署之前，請確定複本延遲接近零，以縮短停機時間。

### Aurora MySQL
<a name="blue-green-deployments-monitor-replica-lag-ms-mdb"></a>

對於 MySQL 藍/綠部署，請檢查綠色環境中的 `AuroraBinlogReplicaLag` CloudWatch 指標，以識別目前的複本延遲。如需詳細資訊，請參閱[診斷和解決僅供讀取複本之間的延遲](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。

### Aurora PostgreSQL
<a name="blue-green-deployments-monitor-replica-lag-pg"></a>

對於的 PostgreSQL 藍/綠部署，請檢查藍色環境中的 `OldestReplicationSlotLag` CloudWatch 指標，以識別目前的複本延遲。如需詳細資訊，請參閱[Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。

此外，您可以在藍色環境中執行下列 SQL 查詢：

```
SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192
```

`confirmed_flush_lsn` 代表傳送至複本的最後一個日誌序號 (LSN)。`pg_current_wal_lsn` 代表資料庫現在所在的位置。`lsn_distance` 為 0 表示複本已跟上進度。

## 切換藍/綠部署
<a name="blue-green-deployments-switching-over"></a>

您可以使用 AWS CLI、 或 RDS API AWS 管理主控台切換藍/綠部署。

### 主控台
<a name="blue-green-deployments-switching-console"></a>

**切換藍/綠部署**

1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。

1. 在導覽窗格中選擇 **Databases** (資料庫)，然後選擇您要切換的藍/綠部署。

1. 針對 **Actions** (動作)，選擇 **Switch over** (切換)。

   **Switch over** (切換) 頁面即會出現。  
![\[切換藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switch-over-aurora.png)

1. 在 **Switch over** (切換) 頁面上，檢閱切換摘要。請確定這兩個環境中的資源符合您預期的資源。如果不符，請選擇 **Cancel** (取消)。

1. 針對**逾時設定**，輸入轉換的時間限制。

1. 如果您的叢集正在執行 Aurora PostgreSQL，請檢閱並確認轉換前建議。如需詳細資訊，請參閱[藍/綠部署的邏輯複寫特定限制](blue-green-deployments-considerations.md#blue-green-deployments-limitations-postgres)。

1. 選擇 **Switch over** (切換)。

### AWS CLI
<a name="blue-green-deployments-switching-cli"></a>

若要使用 切換藍/綠部署 AWS CLI，請使用 [switchover-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html) 命令搭配下列選項：
+ `--blue-green-deployment-identifier`：指定藍/綠部署的資源 ID。
+ `--switchover-timeout` – 指定切換的時間限制，以秒為單位。預設值為 300。

**Example 切換藍/綠部署**  
對於 Linux、macOS 或 Unix：  

```
aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600
```
在 Windows 中：  

```
aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600
```

### RDS API
<a name="blue-green-deployments-switching-api"></a>

若要使用 Amazon RDS API 切換藍/綠部署，請搭配下列參數使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_SwitchoverBlueGreenDeployment.html) 操作：
+ `BlueGreenDeploymentIdentifier`：指定藍/綠部署的資源 ID。
+ `SwitchoverTimeout` – 指定切換的時間限制，以秒為單位。預設值為 300。

## 切換後
<a name="blue-green-deployments-switching-after"></a>

切換後，先前藍色環境中的資料庫叢集和資料庫執行個體會保留下來。標準成本適用於這些資源。藍色和綠色環境之間的複寫和二進位記錄會停止。

RDS 會重新命名藍色環境中的資料庫叢集和資料庫執行個體，方法是將 `-oldn` 附加至目前資源名稱 (其中 `n` 是數字)。藍色資料庫叢集會強制進入唯讀狀態。即使您啟用寫入操作，其仍會保持唯讀狀態，直到您刪除藍/綠部署為止。RDS 會在綠色環境 `-newn` 中為資料庫叢集和資料庫執行個體命名。

如果您刪除藍/綠部署資源，RDS 會保留 `-oldn` 和 `-newn` 資源。

![\[轉換藍/綠部署後\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-after-switchover-aurora.png)


### 更新消費者的父節點
<a name="blue-green-deployments-switching-reparent"></a>

RDS 提供全受管僅供讀取複本。不過，其也提供設定自我管理複本 (也稱為外部複本) 的選項。**外部複本可讓您使用第三方資源作為複寫目標。

在您轉換 Aurora MySQL 藍/綠部署之後，如果藍色資料庫叢集在轉換之前有任何外部複本或二進位日誌消費者，您必須在轉換後更新其父節點，以維持複寫持續性。

**更新父節點**

1. 轉換後，先前在綠色環境中的寫入器資料庫執行個體會發出事件，其中包含主日誌檔案名稱和主日誌位置。若要尋找事件，請瀏覽至 RDS 主控台，然後從左側導覽窗格中選擇**事件**。

1. 在轉換之前，依事件進行篩選，在這些事件中來源為舊的綠色寫入器資料庫執行個體的名稱。

1. 尋找包含二進位日誌座標的事件。事件訊息類似於：`Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 40134574`。

1. 確保消費者或複本已套用舊的藍色環境中的所有二進位日誌。然後，使用提供的二進位日誌座標，在消費者端繼續複寫。例如，如果在 EC2 執行 MySQL 複本，則可以使用下列命令：

   **MySQL 8.0.22 和更低的主要和次要版本**

   ```
   CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=40134574;
   ```

   **MySQL 8.0.23 和更新的主要和次要版本**

   ```
   CHANGE REPLICATION SOURCE TO SOURCE_HOST='{new-writer-endpoint}', SOURCE_LOG_FILE='mysql-bin-changelog.000003', SOURCE_LOG_POS=40134574;
   ```

# 刪除 Amazon Aurora 中的藍/綠部署
<a name="blue-green-deployments-deleting"></a>

您可以在切換藍/綠部署之前或之後將其刪除。

若您在切換藍/綠部署之前將其刪除，Amazon RDS 會選擇性地刪除綠色環境中的資料庫叢集：
+ 如果您選擇刪除綠色環境 (`--delete-target`) 中的資料庫叢集，其必須關閉刪除保護。
+ 如果未刪除綠色環境 (`--no-delete-target`) 中的資料庫叢集，則會保留該叢集，但們不再是藍/綠部署的一部分。對於 Aurora MySQL，複寫會在環境之間繼續。對於 Aurora PostgreSQL，綠色環境會提升為獨立環境，因此複寫會停止。

[切換](blue-green-deployments-switching.md)後，刪除綠色資料庫的選項無法在主控台中使用。當您使用 刪除藍/綠部署時 AWS CLI，如果部署[狀態](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BlueGreenDeployment.html)為 ，則無法指定 `--delete-target`選項`SWITCHOVER_COMPLETED`。

**重要**  
刪除藍/綠部署之後，RDS 會從先前的生產資料庫叢集中移除唯讀保護。如果資料庫叢集的 `read_only` 參數已停用，則會開始再次允許寫入操作。

您可以使用 AWS 管理主控台 AWS CLI、 或 RDS API 刪除藍/綠部署。

## 主控台
<a name="blue-green-deployments-deleting-console"></a>

**刪除藍/綠部署**

1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。

1. 在導覽窗格中選擇 **Databases** (資料庫)，然後選擇您要刪除的藍/綠部署。

1. 對於 **Actions** (動作)，請選擇 **Delete** (刪除)。

   **刪除藍/綠部署？**視窗即會出現。  
![\[刪除藍/綠部署\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-delete-aurora.png)

   若要刪除綠色資料庫，請選取**刪除此藍/綠部署中的綠色資料庫**。

1. 在方塊中輸入 **delete me**。

1. 選擇 **刪除**。

## AWS CLI
<a name="blue-green-deployments-deleting-cli"></a>

若要使用 刪除藍/綠部署 AWS CLI，請使用 [delete-blue-green-deployment](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-blue-green-deployment.html) 命令搭配下列選項：
+ `--blue-green-deployment-identifier`：要刪除的藍/綠部署資源 ID。
+ `--delete-target` – 指定刪除綠色環境中的資料庫叢集。如果藍/綠部署的狀態為 `SWITCHOVER_COMPLETED`，則您無法指定此選項。
+ `--no-delete-target` – 指定保留綠色環境中的資料庫叢集。

**Example 在綠色環境中刪除藍/綠部署和資料庫叢集**  
針對 Linux、macOS 或 Unix：  

```
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --delete-target
```
在 Windows 中：  

```
aws rds delete-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --delete-target
```

**Example 刪除藍/綠部署，但將資料庫叢集保留在綠色環境中**  
針對 Linux、macOS 或 Unix：  

```
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --no-delete-target
```
在 Windows 中：  

```
aws rds delete-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --no-delete-target
```

## RDS API
<a name="blue-green-deployments-deleting-api"></a>

若要使用 Amazon RDS API 刪除藍/綠部署，請搭配下列參數使用 [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteBlueGreenDeployment.html) 操作：
+ `BlueGreenDeploymentIdentifier`：要刪除的藍/綠部署資源 ID。
+ `DeleteTarget` – 指定 `TRUE` 以刪除綠色環境中的資料庫叢集，或指定 `FALSE` 以保留它。如果藍/綠部署的狀態為 `SWITCHOVER_COMPLETED`，則不能為 `TRUE`。