Amazon Aurora 藍/綠部署的最佳實務 - Amazon Aurora

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

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

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

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

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

  • 切換前,請在綠色環境中徹底測試 Aurora 資料庫叢集

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

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

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

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

  • 針對兩個環境中的所有連線,使用叢集端點、讀取器端點或自訂端點。請不要搭配靜態或排除清單使用執行個體端點或自訂端點。

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

Aurora MySQL 藍/綠部署最佳實務

當您從 Aurora MySQL 資料庫叢集建立藍/綠部署時,請考慮下列最佳實務。

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

    • 如果不需要,請停用二進位日誌保留,或暫時停用,直到複寫趕上進度為止。若要這麼做,請將資料庫叢集參數設回 binlog_format0然後重新啟動綠色寫入器資料庫執行個體。

    • 暫時將綠色資料庫innodb_flush_log_at_trx_commit參數群組0中的 參數設為 。複寫追上後,在切換1之前還原為預設值 。如果暫時參數值發生非預期的關機或當機,請重建綠色環境,以避免未偵測到的資料損毀。如需詳細資訊,請參閱 設定日誌緩衝區的排清頻率

藍/綠部署的 Aurora PostgreSQL 最佳實務

當您從 Aurora PostgreSQL 資料庫叢集建立藍/綠部署時,請考慮下列最佳實務。

  • 監控 Aurora PostgreSQL 邏輯複寫直接寫入式快取,如有必要,請對快取緩衝區進行調整。如需詳細資訊,請參閱監控 Aurora PostgreSQL 邏輯複寫寫入快取

  • 在藍色環境中增加logical_decoding_work_mem資料庫參數的值。這樣做允許減少磁碟上的解碼,並改用記憶體。如需詳細資訊,請參閱調整邏輯解碼的工作記憶體

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

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

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

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

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

  • ENABLE ALWAYS 如果在來源上使用觸發來操作資料,請避免將觸發設定為 ENABLE REPLICA或 。否則,複寫系統會傳播變更並執行觸發,這會導致重複。

  • 長時間執行的交易可能會導致顯著的複本延遲。若要減少複本延遲,請考慮執行下列動作:

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

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

    • 在建立藍/綠部署之前,對忙碌資料表啟動手動清空凍結操作。如需說明,請參閱執行手動清空凍結

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

      注意

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

    • 如果工作負載的藍色和綠色資料庫執行個體大小過小,則可能會發生複本延遲。確保您的資料庫執行個體未達到執行個體類型的資源限制。如需詳細資訊,請參閱使用 Amazon CloudWatch 指標來分析 Aurora PostgreSQL 的資源用量

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

  • 檢閱 UPDATE 和 DELETE 陳述式的效能,並評估在 WHERE 子句中使用的資料欄上建立索引是否可以最佳化這些查詢。這可以在綠色環境中重新播放操作時增強效能。如需詳細資訊,請參閱 對產生等待的查詢檢查述詞篩選條件

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

  • 如果在來源資料庫叢集上啟用 Babelfish,則下列參數在綠色環境的目標資料庫叢集參數群組中必須具有與來源資料庫叢集參數群組中相同的設定:

    • rds.babelfish_status

    • babelfishpg_tds.tds_default_numeric_precision

    • babelfishpg_tds.tds_default_numeric_scale

    • babelfishpg_tsql.default_locale

    • babelfishpg_tsql.migration_mode

    • babelfishpg_tsql.server_collation_name

    如需這些參數的相關資訊,請參閱 Babelfish 的資料庫叢集參數群組設定