Amazon RDS 藍/綠部署的最佳實務 - Amazon Relational Database Service

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

Amazon RDS 藍/綠部署的最佳實務

下列是藍/綠部署的最佳實務。

藍/綠部署的一般最佳實務

建立藍/綠部署時,請考慮下列一般最佳實務。

  • 切換前,請在綠色環境中徹底測試資料庫執行個體

  • 在綠色環境中將您的資料庫保留唯讀狀態。建議您在綠色環境上小心啟用寫入操作,因為它們可能會在綠色環境中造成複寫衝突。它們也可能會在切換後於生產資料庫中產生非預期的資料。

  • 使用藍/綠部署實作結構描述變更時,請僅進行複寫相容的變更。

    例如,您可以在資料表尾端新增欄,而不中斷從藍色部署到綠色部署的複寫。不過,結構描述變更 (例如重新命名資料欄或重新命名資料表) 會中斷綠色部署的複寫。

    如需有關複寫相容變更的詳細資訊,請參閱 MySQL 文件中的在來源和複本上使用不同的資料表定義進行複寫,以及 PostgreSQL 邏輯複寫文件中的限制

    注意

    此限制不適用於使用實體複寫的 RDS for PostgreSQL 藍/綠部署。如需詳細資訊,請參閱RDS for PostgreSQL 具有實體複寫的藍/綠部署限制

  • 建立藍/綠部署之後,如有必要,請處理延遲載入。在切換之前,請確定資料載入完成。如需詳細資訊,請參閱藍/綠部署的延遲載入和儲存體初始化

  • 當您切換藍/綠部署時,請遵循切換最佳實務。如需詳細資訊,請參閱切換最佳實務

RDS for MySQL 藍/綠部署最佳實務

當您從 RDS for MySQL 資料庫執行個體建立藍/綠部署時,請考慮下列最佳實務。

  • 避免使用未針對複寫最佳化的非交易式儲存引擎,例如 MyISAM。

  • 針對二進位日誌複寫最佳化僅供讀取複本和綠色環境。如果資料庫引擎支援,請在建立藍/綠部署之前啟用 GTID、平行和當機保護複寫,以確保資料一致性和耐用性。如需詳細資訊,請參閱使用 GTID 式複寫

  • 如果綠色環境遇到複本延遲,請考慮下列事項:

    • 暫時在綠色資料庫參數群組中將 innodb_flush_log_at_trx_commit 參數設為 2。在複寫趕上進度後,在轉換之前還原為預設值 1。如果使用暫時參數值時發生非預期的關機或當機,請重建綠色環境,以避免未偵測到的資料損毀。

    • 為了減少寫入延遲與改善複寫輸送量,請將綠色多個可用區資料庫執行個體暫時變更為單一可用區域資料庫執行個體。在轉換之前重新啟用多個可用區。

RDS for MySQL藍/綠部署最佳實務

除了上述一般和引擎特定最佳實務之外,請考慮下列 RDS for MySQL 資料庫執行個體

  • 監控下列 CloudWatch 指標,以識別生產環境中活動量低的期間:

    • DatabaseConnections

    • ActiveTransactions

    在計劃的維護時段或活動量低的期間,安排藍/綠轉換。

  • 藍/綠轉換持續時間取決於您的工作負載和次要區域的數量。當您啟動藍/綠切換時,服務會等待複本延遲達到零,然後再繼續。我們建議您在開始切換之前檢查複本延遲。

  • 如果您想要使用綠色環境預設參數以外的資料庫參數或資料庫叢集參數群組,請先在所有次要區域中建立名稱相同的所需參數群組,再啟動藍/綠部署。

RDS for PostgreSQL 藍/綠部署的最佳實務

當您從 RDS for PostgreSQL 資料庫執行個體建立藍/綠部署時,請考慮下列最佳實務。

RDS for PostgreSQL 藍/綠部署的一般最佳實務

當您從 RDS for PostgreSQL 資料庫執行個體建立藍/綠部署時,請考慮下列一般最佳實務。

  • 建立藍/綠部署之前,請先將所有 PostgreSQL 延伸模組更新至最新版本。如需詳細資訊,請參閱升級 RDS for PostgreSQL 資料庫中的 PostgreSQL 延伸模組

  • 長時間執行的交易可能會導致嚴重的複本延遲。若要縮短複本延遲,請考慮執行下列動作:

    • 減少長時間執行的交易,這些交易可能會延遲,直到綠色環境趕上藍色環境為止。

    • 減少藍色環境的大量操作,直到綠色環境趕上藍色環境為止。

    • 在建立藍/綠部署之前,對忙碌資料表啟動手動清空凍結操作。

    • 在 PostgreSQL 第 12 版及更新版本中,停用大型或忙碌資料表的 index_cleanup 參數,以提高藍色資料庫正常維護的速率。如需詳細資訊,請參閱盡快清空資料表

      注意

      在清空期間定期略過索引清除可能會導致索引膨脹,而可能會掃描效能下降。根據最佳實務,只有在使用藍/綠部署時,才使用此方法。部署完成後,建議您繼續定期維護和清除索引。

  • 慢速複寫可能會導致寄件者和接收者經常重新啟動,進而延遲同步。若要確保其保持作用中狀態,請在藍色環境中將 wal_sender_timeout 參數設為 0,並在綠色環境中將 wal_receiver_timeout 參數設為 0 以停用逾時。

  • 若要防止預寫日誌 (WAL) 區段從藍色環境中遭到移除,請將 PostgreSQL 第 13 版及更低版本的 wal_keep_segments 參數設為 15625。對於 14 版及更新版本,如果有足夠的可用儲存空間,請將 wal_keep_size 參數設為 1 TiB。

RDS for PostgreSQL 透過實體複寫的藍/綠部署最佳實務

透過實體複寫,Amazon RDS 會建立來源資料庫執行個體的僅供讀取複本。如需相關參數、監控、調校和疑難排解,請參閱使用 Amazon RDS for PostgreSQL 的僅供讀取複本

如需藍/綠部署何時使用實體複寫 (而非邏輯複寫) 的說明,請參閱藍/綠部署的 PostgreSQL 複寫方法

RDS for PostgreSQL 透過邏輯複寫的藍/綠部署最佳實務

當您建立使用邏輯複寫的藍/綠部署時,請考慮下列最佳實務。如需藍/綠部署何時使用邏輯複寫 (而非實體複寫) 的說明,請參閱藍/綠部署的 PostgreSQL 複寫方法

  • 如果資料庫具有足夠的可用記憶體,請在藍色環境中增加 logical_decoding_work_mem 資料庫參數的值。這樣做允許減少磁碟上的解碼,並改用記憶體。如需詳細資訊,請參閱 PostgreSQL 文件

    • 您可以使用 ReplicationSlotDiskUsage CloudWatch 指標監控正在寫入至磁碟的交易溢出。此指標可讓您深入了解複寫槽的磁碟使用情況,協助識別交易資料何時超過記憶體容量與何時存放在磁碟。您可以使用 FreeableMemory CloudWatch 指標來監控可用記憶體。如需詳細資訊,請參閱Amazon RDS 的 Amazon CloudWatch 執行個體層級指標

    • 在 RDS for PostgreSQL 第 14 版及更新版本中,您可以使用 pg_stat_replication_slots 系統檢視來監控邏輯溢出檔案的大小。

  • 如果您使用 aws_s3 延伸模組,請務必在建立綠色環境之後透過 IAM 角色,將綠色資料庫執行個體存取權授與 Amazon S3。這允許匯入和匯出命令在轉換之後繼續運作。如需說明,請參閱設定對 Amazon S3 儲存貯體的存取權

  • 檢閱 UPDATE 和 DELETE 陳述式的效能,以及評估在 WHERE 子句中使用的欄建立索引是否可以最佳化這些查詢。這可以在綠色環境中重播操作時增強效能。

  • 如果您使用的是觸發條件,請確定其不會干擾建立、更新和捨棄名稱開頭為「rds」的 pg_catalog.pg_publicationpg_catalog.pg_subscriptionpg_catalog.pg_replication_slots 物件。

  • 如果您為綠色環境指定較高的引擎版本,請在所有資料庫執行 ANALYZE 操作以重新整理 pg_statistic 資料表。主要版本升級期間不會傳輸最佳化工具統計資料,因此您必須重新產生所有統計資料以避免效能問題。如需主要版本升級期間的其他最佳實務,請參閱如何執行 RDS for PostgreSQL 的主要版本升級

  • 如果在來源使用觸發條件來操作資料,請避免將觸發條件設為 ENABLE REPLICAENABLE ALWAYS。否則,複寫系統會傳播變更與執行觸發條件,而會導致複寫。