設定 RDS for PostgreSQL 的延遲複寫 - Amazon Relational Database Service

設定 RDS for PostgreSQL 的延遲複寫

概觀和優點

RDS for PostgreSQL 中的延遲複寫功能,可讓您刻意延遲將主要資料庫的資料變更複寫到一或多個待命 (僅供讀取複本) 伺服器的作業。藉此可以獲得防止資料損毀、意外資料遺失或錯誤交易的重要機制,以免所有複本立即受到影響。

下列 RDS for PostgreSQL 版本支援延遲複寫:

  • 14.19 和更高的 14 版本

  • 15.14 和更高的 15 版本

  • 16.10 和更高的 16 版本

  • 17.6 和更高的 17 版本

在複寫程序中導入時間延遲後,您將有機會在資料相關事件影響到整個資料庫叢集之前加以偵測並且回應。延遲複寫的主要優點如下:

  • 可讓您在意外刪除、更新或其他邏輯錯誤之後復原。

  • 提供緩衝,防止損毀的資料擴散到您整個資料庫叢集。

  • 提供額外的復原點選項,補強您的傳統備份策略。

  • 可讓您根據組織的特定需求和風險承受能力設定延遲期間。

啟用和設定延遲複寫

若要在 RDS for PostgreSQL 僅供讀取複本上啟用延遲複寫,請依照下列步驟操作:

注意

對於串聯僅供讀取複本,請使用如下所述的相同 recovery_min_apply_delay 參數和步驟。

啟用延遲複寫
  1. 建立新的自訂參數群組,或修改現有群組。如需詳細資訊,請參閱 Amazon RDS 資料庫執行個體的資料庫參數群組

  2. 在新的參數群組中,設定 recovery_min_apply_delay 參數:

    • 將值設定為所需的延遲 (以毫秒為單位)。例如,3600000 代表 1 小時的延遲。

    • 允許的範圍:0 到 86400000 毫秒 (0 到 24 小時)

    • 預設:0

  3. 將參數群組套用至要為延遲複寫設定的僅供讀取複本執行個體。

  4. 將僅供讀取複本執行個體重新開機,讓變更生效。

    注意

    recovery_min_apply_delay 參數是動態的。如果您修改的是已連接至執行個體的現有參數群組,則變更會立即生效,而不需要重新開機。不過,將新的參數群組套用至執行個體時,必須重新開機變更才會生效。

管理延遲複寫復原

在使用傳統時間點復原方法可能不足夠或太耗時的情況下,延遲複寫尤有效用。

在延遲複寫期間,您可以使用下列 PostgreSQL 函數來管理復原程序:

  • pg_wal_replay_pause():要求暫停延遲複本上的復原程序。

  • pg_wal_replay_resume():在復原程序先前已暫停的情況下,予以重新啟動。

  • pg_is_wal_replay_paused():檢查復原程序目前是否暫停。

  • pg_get_wal_replay_pause_state():取得復原程序的目前狀態 (未暫停、已要求暫停或已暫停)。

具有 rds_superuser 角色的使用者在 pg_wal_replay_pause()pg_wal_replay_resume() 上具有 EXECUTE 權限。如果其他資料庫使用者需要存取這些函數,您必須為他們授予 rds_superuser 角色。如需 rds_superuser 角色的詳細資訊,請參閱 了解 rds_superuser 角色

存取其他函數 (例如 pg_is_wal_replay_paused()pg_get_wal_replay_pause_state()) 不需要 rds_superuser 角色。

您可以使用下列復原目標參數,精確控制延遲複本要復原到的時間點。這些參數是靜態的,必須將資料庫重新開機才能套用變更:

  • recovery_target

  • recovery_target_lsn

  • recovery_target_name

  • recovery_target_time

  • recovery_target_xid

  • recovery_target_inclusive

重要

您一次只能指定一個復原目標參數。在組態檔中設定多個復原目標參數,會導致錯誤。

規劃考量

規劃 RDS for PostgreSQL 的延遲複寫時,請考量下列事項:

  • rdsrepladmin 憑證的自動輪換期間 (每 90 天發生一次),延遲的僅供讀取複本可能會暫時進入 REPLICATION_ERROR 狀態。如果延遲複本有足夠的 WAL 日誌可維持設定的延遲,則可能會暫停 WAL 接收器程序,而在來源上導致 WAL 累積。您應監控複本上的複寫狀態,以及來源上的儲存體耗用量,以避免達到儲存已滿狀態。

  • 延遲的僅供讀取複本在經歷系統事件 (例如重新開機或重新啟動) 時,會進入 WAL 接收器程序保持非作用中的 REPLICATION_ERROR 狀態,直到設定的延遲期間到期為止。此行為可能會造成來源執行個體上的 WAL 累積,進而導致儲存體耗盡。請考量下列預防措施:

    • 設定 CloudWatch 警示,以監控來源執行個體上的儲存體使用率。

    • 啟用儲存體自動調整功能,以處理非預期的 WAL 增長。

    • 在來源執行個體上設定 max_slot_wal_keep_size 參數,以限制每個複寫插槽的 WAL 保留期。

    • 定期監控複寫延遲和插槽狀態。

  • 較長的延遲會增加複本上的 WAL 日誌,而耗用更多儲存體。使用 CloudWatch 警示監控儲存空間、啟用自動調整,或在需要時同步複本。

  • 在提升延遲的僅供讀取複本時不會接受 recovery_min_apply_delay 參數,且會立即套用所有待處理的 WAL 記錄。

  • recovery_min_apply_delay 參數在階層式複寫設定的各個層級是獨立的。在複本上設定的延遲,並不會新增至任何階層式複本的延遲。

如需詳細資訊,請參閱 RDS for PostgreSQL 僅供讀取複本文件RDS for PostgreSQL 災難復原文件

了解限制

Amazon RDS for PostgreSQL 的延遲複寫功能有下列限制:

  • 在設定延遲複寫時,藍/綠部署有下列限制:

    • 綠色來源執行個體 — 即使設定於參數群組中,recovery_min_apply_delay parameter 仍會被忽略。綠色來源執行個體上的任何延遲設定都不會生效。

    • 綠色複本執行個體recovery_min_apply_delay parameter 完全受支援,且會套用至 PostgreSQL 組態檔。在轉換工作流程期間,延遲設定會正常運作。

    • 主要版本升級的 RDS 藍/綠部署

  • 在主要版本升級期間,任何延遲的僅供讀取複本都會自動終止,以允許來源執行個體繼續升級程序,確保能盡可能縮短停機時間。來源執行個體完成升級後,您必須手動重新建立延遲的複本。

  • 延遲複寫與下列功能不相容。

    • RDS for PostgreSQL 邏輯複寫

    • RDS for PostgreSQL 多可用區域叢集 (包括傳入和傳出複寫)

    • Aurora PostgreSQL