本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在 Amazon Aurora 中切換藍/綠部署
*轉換*會在綠色環境中將資料庫叢集 (包括其資料庫執行個體) 轉換為生產資料庫叢集。切換前，生產流量會路由到藍色環境中的叢集。切換後，生產流量會路由到綠色環境中的資料庫叢集。
*轉換*藍/綠部署與在藍/綠部署中*提升*綠色資料庫叢集不同。如果您透過從**動作**功能表中選擇**提升**，手動提升綠色資料庫叢集，則藍色和綠色環境之間的複寫會中斷，且藍/綠部署會進入**無效組態**的狀態。
**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)
## 切換逾時
您可以指定介於 30 秒與 3,600 秒(一小時) 之間的切換逾時期間。如果切換所花費的時間超過指定的持續時間，則會復原任何變更，且不會對任一環境進行任何變更。預設逾時期間為 300 秒 (五分鐘)。
## 切換防護機制
當您開始切換時，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`，並通知您無法對藍/綠部署進行轉換。若要繼續進行轉換，建議您刪除並重新建立藍/綠部署和所有綠色資料庫。若要這樣做，請選擇**動作**、**刪除綠色資料庫**。
## 切換動作
當您切換藍/綠部署時，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)。
如果切換開始，然後在完成前由於任何原因而停止，則會復原任何變更，且不會對任一環境進行任何變更。
## 切換最佳實務
在您轉換之前，我們強烈建議您完成下列任務，以遵守最佳實務：
+ 徹底測試綠色環境中的資源。確保它們正常有效地執行。
+ 監控相關 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 指標
轉換藍/綠部署之前，建議您檢查 Amazon CloudWatch 中下列指標的值。
+ `DatabaseConnections` – 使用此指標估計藍/綠部署的活動層級，並在切換前確認該值處於部署的可接受層級。如果績效詳情已開啟，則 `DBLoad` 為更準確的指標。
+ `ActiveTransactions` – 若在任何資料庫執行個體中，資料庫參數群組中的 `innodb_monitor_enable` 設為 `all`，請使用此指標來查看是否有大量作用中交易可能封鎖切換。
如需詳細資訊，請參閱[Amazon Aurora 的 Amazon CloudWatch 指標](Aurora.AuroraMonitoring.Metrics.md)。
## 轉換前監控複本延遲
在轉換藍/綠部署之前，請確定複本延遲接近零，以縮短停機時間。
### Aurora MySQL
對於 MySQL 藍/綠部署，請檢查綠色環境中的 `AuroraBinlogReplicaLag` CloudWatch 指標，以識別目前的複本延遲。如需詳細資訊，請參閱[診斷和解決僅供讀取複本之間的延遲](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。
### Aurora PostgreSQL
對於的 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 表示複本已跟上進度。
## 切換藍/綠部署
您可以使用 AWS CLI、 或 RDS API AWS 管理主控台切換藍/綠部署。
### 主控台
**切換藍/綠部署**
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
若要使用 切換藍/綠部署 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
若要使用 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。
## 切換後
切換後，先前藍色環境中的資料庫叢集和資料庫執行個體會保留下來。標準成本適用於這些資源。藍色和綠色環境之間的複寫和二進位記錄會停止。
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)
### 更新消費者的父節點
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;
```