切換藍/綠部署 - Amazon Aurora
切換逾時切換防護機制切換動作切換最佳實務切換前驗證 CloudWatch 指標在切換之前監視複本延遲切換藍/綠部署切換後

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

切換藍/綠部署

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

切換藍/綠部署與在藍/綠部署中提升綠色資料庫叢集並不相同。如果您從「動作」功能表選擇「升級」來手動升級綠色資料資料庫叢集，藍色和綠色環境之間的複寫會中斷，而藍/綠部署會進入「無效」組態的狀態。

切換逾時

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

切換防護機制

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

Amazon 對綠色環境RDS執行以下護欄檢查：

  • 複寫運作狀態 – 檢查綠色資料庫叢集複寫狀態是否良好。綠色資料庫叢集是藍色資料庫叢集的複本。

  • 複寫延遲 – 檢查綠色資料庫叢集的複本延遲是否在轉換的允許限制內。允許的限制是以指定的逾時期間為基礎。複本延遲指出綠色資料庫叢集落後於其藍色資料庫叢集多遠。有關更多信息，請診斷和解決僅供讀取複本之間的延遲參閱 Aurora 我 Aurora Post SQL gre。

  • 作用中寫入 – 確定綠色資料庫叢集上沒有作用中寫入。

Amazon 對藍色環境RDS執行以下護欄檢查：

  • 外部複寫 — 對於 Postgre 的 Aurora 者)。如果是這樣，建議您將自我管理的複寫插槽和訂閱放置在藍色環境中的所有資料庫，繼續進行轉換，然後重新建立它們以繼續複寫。對SQL檢查藍色資料庫是否不是外部 binlog 複本。如果是，請確保它沒有主動複製。

  • 長時間執行的作用中寫入 – 確定藍色資料庫叢集上沒有長時間執行的作用中寫入，因為這些寫入可能會增加複本延遲。

  • 長時間執行的DDL陳述式 — 確定藍色行的DDL陳述式，因為它們可能會增加複本延遲。

  • 不支援的 Postgre SQL 變更 — 對於 Postgre SQL 資料庫執行叢集，請確保在藍色環境中未執行任何DDL變更，也不會新增或修改大型物件。如需詳細資訊，請參閱藍/綠部署的SQL發生邏輯複製限制。

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

切換動作

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

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

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

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

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

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

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

    RDS例如，假設藍色環境中資料庫執行個體的名稱為 mydb。切換後，資料庫執行個體名稱可能是 mydb-old1。

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

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

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

    轉換後，先前的生產叢集只允許讀取作業，為止。即使您停用資料庫叢集上的read_only參數，它仍會保持唯讀狀態，直到您刪除藍/綠部署為止。

您可以使用 Amazon 監控轉換的狀態。 EventBridge如需詳細資訊，請參閱藍/綠部署事件。

如果您在藍色環境中配置了標籤，則這些標籤會在轉換期間複製到新的生產環境中。如需標籤的詳細資訊，請參閱標記 Amazon Aurora 和 Amazon RDS 資源。

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

切換最佳實務

在您轉換之前，我們強烈建議您完成下列任務，以遵守最佳實務：

  • 徹底測試綠色環境中的資源。確保它們正常有效地執行。

  • 監控相關的 Amazon CloudWatch 指標。如需詳細資訊，請參閱切換前驗證 CloudWatch 指標。

  • 識別切換的最佳時間。

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

    如果您的資料庫叢集和資料庫執行個體上有大量連線，請考慮在切換藍/綠部署之前，手動將其減少到應用程式所需的最低數量。達成此目標的方法之一是建立一項指令碼，用以監控藍/綠部署狀態，並在偵測到狀態變更至 SWITCHOVER_IN_PROGRESS 時開始清除連線。

  • 確定這兩個環境中的資料庫叢集和資料庫執行個體處於 Available 狀態。

  • 確定綠色環境中的資料庫叢集運作良好且複寫中。

  • 請確定您的網路和用戶端設定不會將DNS快取存留時間 (TTL) 增加到超過五秒，這是 Aurora DNS區域的預設值。
 否則，應用程式會在切換之後繼續將寫入流量傳送至藍色環境。

  • 對於 Postgre SQL 資料庫執行個體RDS的 Aurora SQL 資料庫叢集動作：

    • 檢閱邏輯複寫限制，並在切換之前採取任何必要的動作。如需詳細資訊，請參閱藍/綠部署的SQL發生邏輯複製限制。

    • 執行 ANALYZE 操作以重新整理 pg_statistics 資料表。這樣可以降低轉換後發生效能問題的風險。

注意

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

切換前驗證 CloudWatch 指標

在切換藍/綠部署之前，我們建議您在 Amazon CloudWatch 中檢查以下指標的值。

  • DatabaseConnections – 使用此指標估計藍/綠部署的活動層級，並在切換前確認該值處於部署的可接受層級。如果績效詳情已開啟，則 DBLoad 為更準確的指標。

  • ActiveTransactions – 若在任何資料庫執行個體中，資料庫參數群組中的 innodb_monitor_enable 設為 all，請使用此指標來查看是否有大量作用中交易可能封鎖切換。

如需這些指標的詳細資訊，請參閱 Amazon Aurora 的 Amazon CloudWatch 指標。

在切換之前監視複本延遲

在切換藍/綠部署之前，請確定綠色資料庫上的複本延遲接近零，以減少停機時間。

  • 對於 Aurora MySQL，請使用AuroraBinlogReplicaLag CloudWatch 指標來識別綠色環境上目前的複寫延遲。

  • 對於 Aurora 波斯特雷SQL，請使用以下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 Management Console，該 AWS CLI，或 RDSAPI.

切換藍/綠部署

  1. 登入 AWS Management Console 並在打開 Amazon RDS 控制台https://console.aws.amazon.com/rds/。

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

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

    Switch over (切換) 頁面即會出現。

    切換藍/綠部署

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

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

  6. 如果您的叢集執行 Aurora Postgre SQL ，請檢閱並確認切換前的建議。如需詳細資訊，請參閱藍/綠部署的SQL發生邏輯複製限制。

  7. 選擇 Switch over (切換)。

若要使用以切換藍/綠部署 AWS CLI，搭配下列選項使用switchover-blue-green-deployment指令：

  • --blue-green-deployment-identifier— 指定藍/綠部署的資源 ID。

  • --switchover-timeout – 指定切換的時間限制，以秒為單位。預設值為 300。

範例 切換藍/綠部署

用於 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

要使用 Amazon 切換藍/綠部署 RDSAPI，請使用具有以下參數的SwitchoverBlueGreenDeployment操作：

  • BlueGreenDeploymentIdentifier— 指定藍/綠部署的資源 ID。

  • SwitchoverTimeout – 指定切換的時間限制，以秒為單位。預設值為 300。

切換後

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

RDS數據庫集群被強制進入只讀狀態。即使您停用資料庫叢集上的read_only參數，它仍會保持唯讀狀態，直到您刪除藍/綠部署為止。RDS在綠色環境中命名資料庫行個體叢集和資料庫執行個體-newn。

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

切換為藍色/綠色部署之後

更新消費者的父節點

切換 的藍SQL/綠部署後，如果藍色叢集在切換之前有任何外部複本或二進位記錄取用者，則必須在切換後更新其父節點，以維持複寫連續性。

切換之後，先前位於綠色環境中的寫入器資料庫執行個體會發出包含主記錄檔名稱和主記錄位置的事件。例如：

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

首先，請確定取用者或複本已套用舊藍色環境中的所有二進位記錄檔。然後，使用提供的二進制日誌坐標恢復消費者的應用程序。例如，如果您正在執行我的SQL複本EC2，則可以使用以下CHANGE MASTER TO命令：

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