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

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

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

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

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

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

**Topics**
+ [藍/綠部署的一般限制](#blue-green-deployments-limitations-general)
+ [藍/綠部署的 RDS for MySQL 限制](#blue-green-deployments-limitations-mysql)
+ [RDS for PostgreSQL 具有實體複寫的藍/綠部署限制](#blue-green-deployments-limitations-postgres-physical)
+ [RDS for PostgreSQL 藍/綠部署限制 (使用邏輯複寫)](#blue-green-deployments-limitations-postgres-logical)

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

下列一般限制適用於藍/綠部署：
+ 藍/綠部署不支援使用 AWS Secrets Manager管理主要使用者密碼。
+ 如果在藍色資料庫啟用專用日誌磁碟區 (DLV)，則必須在*所有*資料庫執行個體 (包括僅供讀取複本) 啟用此功能。
+ 在切換期間，藍色和綠色環境無法與 Amazon Redshift 進行零 ETL 整合。您必須先刪除整合再進行切換，然後重新建立整合。
+ 建立藍/綠部署時，必須在綠色環境上停用事件排程器 (`event_scheduler` 參數)。這樣可以防止在綠色環境中產生事件並導致不一致。
+ 您無法將未加密的資料庫執行個體變更為加密的資料庫執行個體。此外，您無法將加密的資料庫執行個體變更為未加密的資料庫執行個體。
+ 您無法將藍色資料庫執行個體變更為高於其對應綠色資料庫執行個體的引擎版本。
+ 藍色環境和綠色環境中的資源必須在同一 AWS 帳戶中。
+ 下列功能不支援藍/綠部署：
  + Amazon RDS Proxy
  + 階層式僅供讀取複本
  + 跨區域僅供讀取複本
  + CloudFormation
  + Multi-AZ 資料庫叢集部署

    支援藍/綠部署進行多可用區域資料庫執行個體部署。如需多可用區域部署的詳細資訊，請參閱 [設定及管理 Amazon RDS 的多可用區域部署](Concepts.MultiAZ.md)。

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

下列限制適用於 RDS for MySQL 藍/綠部署：
+ 藍色資料庫執行個體不能是外部 binlog 複本。
+ 如果來源資料庫與自訂選項群組相關聯，則您無法在建立藍/綠部署時指定主要版本升級。

  在此情況下，您可以建立藍/綠部署，而無需指定主要版本升級。然後，您可以在綠色環境中升級資料庫。如需詳細資訊，請參閱[升級資料庫執行個體 引擎版本](USER_UpgradeDBInstance.Upgrading.md)。
+ 藍/綠部署不支援 AWS JDBC Driver for MySQL。如需詳細資訊，請參閱在 GitHub 的[已知限制](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations)。

### RDS for PostgreSQL 具有實體複寫的藍/綠部署限制
<a name="blue-green-deployments-limitations-postgres-physical"></a>

下列限制適用於使用實體複寫的 RDS for PostgreSQL 藍/綠部署。如需藍/綠部署何時使用實體複寫 (而非邏輯複寫) 的說明，請參閱[藍/綠部署的 PostgreSQL 複寫方法](blue-green-deployments-replication-type.md)。
+ 建立綠色環境後，您就無法執行手動主要版本升級。
+ 使用實體複寫的藍/綠部署不支援綠色環境中的結構描述變更，因為此變更是嚴格地唯讀。
+ 藍色資料庫執行個體不能是邏輯來源 (發布者) 或複本 (訂閱用戶)。
+ 在 RDS for PostgreSQL 中設定延遲複寫時，藍/綠部署有下列限制：
  + **綠色來源執行個體** — 即使設定於參數群組中，`recovery_min_apply_delay parameter` 仍會被忽略。綠色來源執行個體上的任何延遲設定都不會生效。
  + **綠色複本執行個體** — `recovery_min_apply_delay parameter` 完全受支援，且會套用至 PostgreSQL 組態檔。在轉換工作流程期間，延遲設定會正常運作。
  + 延遲複寫與主要版本升級的 RDS 藍/綠部署不相容。

### RDS for PostgreSQL 藍/綠部署限制 (使用邏輯複寫)
<a name="blue-green-deployments-limitations-postgres-logical"></a>

下列限制適用於 RDS for PostgreSQL 藍/綠部署 (使用邏輯複寫)。如需藍/綠部署何時使用邏輯複寫 (而非實體複寫) 的說明，請參閱[藍/綠部署的 PostgreSQL 複寫方法](blue-green-deployments-replication-type.md)。
+ 。
+ 藍色資料庫執行個體不能是邏輯來源 (發布者) 或複本 (訂閱用戶)。
+ 如果藍色資料庫執行個體設定為外部資料包裝函式 (FDW) 延伸模組的外部伺服器，您必須使用執行個體端點名稱，而非 IP 位址。這可讓組態在轉換之後保持運作狀態。
+ 在藍/綠部署中，每個資料庫都需要邏輯複寫槽。隨著資料庫數量的增加，資源負荷會增加，並可能導致複寫延遲，特別是當資料庫執行個體未充分擴展時。此影響取決於資料庫工作負載和連線數量等因素。若要緩解此問題，請考慮擴展資料庫執行個體類別，或減少來源執行個體的資料庫數目。
+ 在綠色環境中邏輯複寫[套用程序](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)等替代方法。
+ 在 RDS for PostgreSQL 中設定延遲複寫時，藍/綠部署有下列限制：
  + **綠色來源執行個體** — 即使設定於參數群組中，`recovery_min_apply_delay parameter` 仍會被忽略。綠色來源執行個體上的任何延遲設定都不會生效。
  + **綠色複本執行個體** — `recovery_min_apply_delay parameter` 完全受支援，且會套用至 PostgreSQL 組態檔。在轉換工作流程期間，延遲設定會正常運作。
  + 延遲複寫與主要版本升級的 RDS 藍/綠部署不相容。
+ 在 RDS for PostgreSQL 的藍/綠部署期間，不支援在分割資料表建立新的分割區。建立新的分割區涉及資料定義語言 (DDL) 操作 (例如 `CREATE TABLE`)，系統不會將這些操作從藍色環境複寫到綠色環境。不過，系統會將現有的分割資料表及其資料複寫至綠色環境。
+ 下列限制適用於 PostgreSQL 延伸模組：
  + 建立藍/綠部署時，必須在藍色環境中停用 `pg_partman` 延伸模組。延伸模組會執行 DDL 作業 (例如 `CREATE TABLE`)，其會中斷從藍色環境到綠色環境的邏輯複寫。
  + 建立藍/綠部署之後，所有綠色資料庫上的 `pg_cron` 延伸模組必須保持停用狀態。延伸模組具有以超級使用者身分執行的背景工作者，且會略過綠色環境的唯讀設定，這可能會造成複寫衝突。
  + 建立藍/綠部署時，必須在藍色環境上停用 `pglogical` 和 `pgactive` 延伸模組。將綠色環境切換為新的生產環境之後，您可以再次啟用延伸模組。此外，藍色資料庫不能是外部執行個體的邏輯訂閱者。
  + 如果您使用的是 `pgAudit` 延伸模組，其必須保留在藍色和綠色資料庫執行個體的自訂資料庫參數群組上的共用程式庫 (`shared_preload_libraries`) 中。如需詳細資訊，請參閱[設定 pgAudit 擴充功能](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)。

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

PostgreSQL 具有某些與邏輯複寫相關的限制，其會在針對 RDS for PostgreSQL 資料庫執行個體建立藍/綠部署時轉換為限制。

下表描述適用於 RDS for PostgreSQL 藍/綠部署的邏輯複寫限制。如需詳細資訊，請參閱 PostgreSQL 邏輯複寫文件中的[限制](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。


| 限制 | 說明 | 
| --- | --- | 
| 資料定義語言 (DDL) 陳述式 (例如 CREATE TABLE 和 CREATE SCHEMA) 不會從藍色環境複寫到綠色環境。 |  如果 Amazon RDS 在藍色環境中偵測到 DDL 變更，則您的綠色資料庫會進入**複寫降級**狀態。您必須刪除藍/綠部署和所有綠色資料庫，然後重新建立該部署。  | 
| 系統不會將資料控制語言 (DCL) 陳述式 (例如 GRANT 和 REVOKE) 從藍色環境複寫到綠色環境。 |  如果 Amazon RDS PostgreSQL 偵測到有人嘗試在藍色環境中執行 DCL 陳述式，您將看到警告訊息。沒有可供變更此行為的組態或 API，因為其是藍/綠部署程序的限制。  | 
| 序列物件上的 NEXTVAL 作業不會在藍色環境與綠色環境之間同步。 |  在轉換期間，Amazon RDS 會在綠色環境中遞增序列值，以符合藍色環境中的序列值。如果您有數千個序列，這可能會延遲轉換。  | 
| 藍色環境中的大型物件不會複寫到綠色環境。這包括現有的大型物件，以及藍/綠部署程序期間任何新建或修改的大型物件。 |  如果 Amazon RDS 在藍色環境中偵測到 `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)。  | 

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

Amazon RDS 會使用每個資源的 `DbiResourceId` 追蹤藍/綠部署中的資源。此資源 ID 是 資源 AWS 區域的唯一不可變識別符。

*資源* ID 與資料庫***執行個體* ID 不同。在 RDS 主控台的資料庫組態中會列出每一項。

當您切換藍/綠部署時，資源的名稱 (執行個體 ID) 會變更，但每個資源都保留相同的資源 ID。例如，資料庫執行個體識別符可能是藍色環境中的 `mydb`。切換後，相同的資料庫執行個體可能重新命名為 `mydb-old1`。不過，資料庫執行個體的資源 ID 在切換期間不會變更。因此，將綠色資源轉換為新的生產資源時，其資源 ID 與先前位於生產環境中的藍色資源 ID 不符。

在切換藍/綠部署之後，請考慮將資源 ID 更新為新轉換之生產資源的 ID，以取得與生產資源搭配使用的整合功能和服務。具體來說，請考慮下列更新：
+ 如果您使用 RDS API 和資源 ID 執行篩選，請在切換後調整用於篩選的資源 ID。
+ 如果您使用 CloudTrail 來稽核資源，請調整 CloudTrail 的取用者，以在切換後追蹤新的資源 ID。如需詳細資訊，請參閱[在 AWS CloudTrail 中監控 Amazon RDS API 呼叫](logging-using-cloudtrail.md)。
+ 如果您使用 Performance Insights API，請在切換後調整 API 呼叫中的資源 ID。如需詳細資訊，請參閱[在 Amazon RDS 上使用績效詳情監控資料庫負載](USER_PerfInsights.md)。

  您可以在切換後監控具有相同名稱的資料庫，但其不包含切換前的資料。
+ 如果您在 IAM 政策中使用資源 ID，請務必在必要時新增新轉換資源的資源 ID。如需詳細資訊，請參閱[Amazon RDS 的 Identity and access management](UsingWithRDS.IAM.md)。
+ 如果您有與資料庫執行個體相關聯的 IAM 角色，請務必在轉換後重新建立關聯。連接的角色不會自動複製到綠色環境。
+ 如果您使用 [IAM 資料庫身份驗證](UsingWithRDS.IAMDBAuth.md)對資料庫執行個體進行身分驗證，請確定用於資料庫存取的 IAM 政策同時具有政策 `Resource` 元素下方列出的藍色和綠色資料庫。這是必要的，以便在切換後連線到綠色資料庫。如需詳細資訊，請參閱[建立並使用 IAM 政策進行 IAM 資料庫存取](UsingWithRDS.IAMDBAuth.IAMPolicy.md)。
+ 如果您使用 AWS Backup 來管理藍/綠部署中資源的自動備份，請在切換 AWS Backup 後調整 所使用的資源 IDs。如需詳細資訊，請參閱[使用 AWS Backup 來管理 Amazon RDS 的自動備份](AutomatedBackups.AWSBackup.md)。
+ 如果您想要還原屬於藍/綠部署之資料庫執行個體的手動或自動資料庫快照，請確定透過檢查取得快照的時間來還原正確的資料庫快照。如需詳細資訊，請參閱[還原至資料庫執行個體](USER_RestoreFromSnapshot.md)。
+ 如果您想要描述先前的藍色環境資料庫執行個體自動備份，或將其還原到某個時間點，請將資源 ID 用於操作。

  因為資料庫執行個體的名稱會在切換期間變更，所以您無法將其先前的名稱用於 `DescribeDBInstanceAutomatedBackups` 或 `RestoreDBInstanceToPointInTime` 操作。

  如需詳細資訊，請參閱[將 Amazon RDS 的資料庫執行個體還原至指定時間](USER_PIT.md)。
+ 若您在藍/綠部署的綠色環境中將僅供讀取複本新增至資料庫執行個體，則在切換時，新的僅供讀取複本不會取代藍色環境中的僅供讀取複本。不過，新的僅供讀取複本會在切換後保留在新的生產環境中。
+ 切換後，由於藍色環境的檢查點在綠色環境中無效，因此 AWS Database Migration Service (AWS DMS) 複寫任務無法繼續。您必須使用新檢查點重新建立 DMS 任務，才能繼續複寫。
+ 在藍/綠部署的綠色環境中刪除資料庫執行個體時，您無法建立新的資料庫執行個體，以在藍/綠部署中取代該執行個體。

  如果您使用與所刪除資料庫執行個體相同的名稱和 Amazon Resource Name (ARN) 建立的新資料庫執行個體，則它具有不同的 `DbiResourceId`，因此不屬於綠色環境。

  如果您刪除綠色環境中的資料庫執行個體，則會產生下列行為：
  + 如果藍色環境中存在名稱相同的資料庫執行個體，則它不會切換至綠色環境中的資料庫執行個體。此資料庫執行個體不會透過將 `-oldn` 新增至資料庫執行個體名稱來重新命名。
  + 指向藍色環境中資料庫執行個體的任何應用程式都會在切換後繼續使用相同的資料庫執行個體。

  相同的行為適用於資料庫執行個體和僅供讀取複本。
+ 如果您使用資源標籤進行存取控制或操作管理，則需要了解在切換之前，藍色和綠色環境之間不會同步標籤變更。當您建立藍/綠部署時，藍環境的標籤會複製到綠色環境。建立之後，您對任一環境所做的任何標籤修改都不會自動同步。在切換期間，藍色環境標籤會取代綠色環境中的所有標籤。在建立藍/綠部署之前，請將所有必要的標籤套用至藍環境，或在切換後將必要的標籤重新套用至新的生產環境。如需標籤的詳細資訊，請參閱[標記 Amazon RDS 資源](USER_Tagging.md)。