使用備份功能保護資料

選取說明文件版本：

本頁面說明 AlloyDB Omni 標準可用性參考架構，該架構使用備份提供資料保護。

用途

這項參考架構支援下列情境：

  • 您的資料庫可以容忍自上次備份以來的部分停機時間和資料遺失。
  • 您想保護 AlloyDB Omni 資料庫，避免資料庫層級 (而非伺服器或 VM 映像檔快照) 發生使用者錯誤、損毀或實體故障。
  • 您希望能夠在本機或遠端復原資料庫，甚至復原至特定時間點。

參考架構的運作方式

標準可用性參考架構涵蓋 AlloyDB Omni 資料庫的備份與復原，無論資料庫是以獨立執行個體的形式在主機伺服器上執行、以虛擬機器的形式執行 (安裝 AlloyDB Omni)，或是在 Kubernetes 叢集中執行 (在 Kubernetes 上安裝 AlloyDB Omni)，都適用此架構。

雖然標準可用性是基本實作，且可盡量減少所需的額外硬體或服務，但復原時間目標 (RTO) 會隨著資料庫變大而增加。要備份的資料越多，還原及復原資料庫所需的時間就越長。資料遺失情況取決於備份類型。如果只定期備份資料檔案，還原時就會遺失上次備份後的資料。

縮短 RPO

PostgreSQL 的持續封存 功能可讓您達成低復原點目標 (RPO)，並透過備份啟用時間點復原功能。這項程序包括封存預寫記錄檔 (WAL) 和串流 WAL 資料，可能需要傳送至遠端儲存空間位置。

如果 WAL 檔案只在填滿或特定時間間隔時封存，則完整資料庫遺失 (包括目前的 WAL 檔案) 會限制復原至最後一個封存的 WAL 檔案，這表示復原點目標 (RPO) 必須考量潛在的資料遺失。相反地，持續傳輸 WAL 資料可盡可能避免資料遺失。

執行持續備份時，您可以還原至特定時間點。時間點復原功能可讓您將資料庫還原至錯誤發生前的狀態，例如不小心刪除資料表或批次更新錯誤。不過，除非使用臨時輔助資料庫，否則這種復原方法會影響復原點目標 (RPO)。

備份策略

您可以設定 AlloyDB Omni Postgres 層級備份，儲存在本機或遠端儲存空間。雖然本機儲存空間的備份和復原速度可能較快，但當整個主機或 VM 故障時，遠端儲存空間通常能更有效地處理故障。

非 Kubernetes 備份

如為非 Kubernetes 部署項目，您可以使用下列 PostgreSQL 工具排定備份作業：

或者，如果是小型資料庫，您可以選擇執行資料庫的邏輯備份 (使用 pg_dump 備份單一資料庫，或使用 pg_dumpall 備份整個叢集)。您可以使用 pg_restore 還原。

使用 AlloyDB Omni operator 在 Kubernetes 中備份

如果是部署在 Kubernetes 叢集中的 AlloyDB Omni，您可以為每個資料庫叢集設定備份方案，藉此設定持續備份。詳情請參閱「在 Kubernetes 中備份及還原」。

您可以將 AlloyDB Omni 備份儲存在本機，或遠端儲存在 Cloud Storage，包括任何雲端供應商提供的選項。詳情請參閱圖 1，瞭解可能的備份目的地。

AlloyDB Omni 備份選項

圖 1.AlloyDB Omni 備份選項。

備份可儲存至本機或遠端儲存空間。本機備份通常較快，因為只會用到 I/O 處理量，而遠端備份的延遲時間通常較長，網路頻寬也較低。不過，遠端備份可提供最佳保護，包括可用區故障。

您也可以將本機備份分割至本機或共用儲存空間。雖然本機儲存空間選項會受到資料庫主機故障時缺乏災難復原選項的影響，但共用儲存空間可將該儲存空間重新定位到其他伺服器，然後用於復原。這表示共用儲存空間可能提供更快的 RTO。

如果是本機和共用儲存空間部署作業，系統可能會排定下列類型的備份作業，或在您要求時手動執行：

  • 完整備份：完整備份資料復原所需的所有資料庫檔案。
  • 差異備份：只備份上次完整備份後出現的檔案變更。
  • 增量備份：只備份上次備份後出現的檔案異動。

時間點復原

PostgreSQL 預寫記錄 (WAL) 檔案的持續備份功能支援時間點復原。如果發生失敗事件後，WAL 檔案仍完好無損且可用，您就能使用這些檔案復原，不會遺失任何資料。

如要控管 WAL 檔案的寫入作業，可以設定下列參數：

參數 說明

wal_writer_delay

指定 WAL 寫入器將 WAL 排清至磁碟的頻率，除非交易以非同步方式提交，提早喚醒寫入作業。預設值為 200 毫秒。提高這個值會降低寫入頻率，但如果伺服器當機，可能會增加遺失的資料量。

wal_writer_flush_after

指定 WAL 寫入器強制將資料排清至磁碟前，可累積多少 WAL 資料。預設值為 1MB。如果設為零，系統一律會立即將 WAL 資料排清至磁碟。

synchronous_commit

指定提交作業是否要在 WAL 資料排清至磁碟前，將回應傳回給使用者。預設設定為 on，可確保交易持久性。換句話說，在將成功代碼傳回給使用者之前，系統已將提交內容寫入磁碟。如果設為 off，則交易寫入磁碟前最多會經過 wal_writer_delay 次。

監控 WAL 使用量

您可以使用下列方法觀察 WAL 使用情形：

觀察方法 說明

pg_stat_wal

這個標準檢視表包含 wal_write 和 wal_sync 資料欄，用於儲存 WAL 寫入和 WAL 同步處理的次數。啟用設定參數 track_wal_io_timing 後，系統也會儲存 wal_write_time 和 wal_sync_time。定期擷取這個檢視畫面，有助於顯示一段時間內的 WAL 寫入和同步活動。
pg_current_wal_lsn() 這個函式會傳回目前的記錄序號 (lsn) 位置，如果與時間戳記建立關聯，並隨著時間收集為快照，就能提供使用 pg_wal_lsn_diff(lsn1, lsn2) 函式產生的 WAL 每秒位元組數。這項函式是實用的指標，可協助您瞭解交易率和 WAL 檔案的效能。

將 WAL 資料串流至遠端位置

使用 Barman 時，您也可以設定將 WAL 資料即時串流至遠端位置，確保復原時幾乎不會遺失資料。雖然是即時串流，但由於串流寫入遠端 Barman 伺服器的作業預設為非同步，因此仍有極小的機率會遺失已提交的交易。不過，您可以使用同步模式設定 WAL 串流，該模式會儲存 WAL，並將狀態回應傳回來源資料庫。請注意，如果交易必須等待這項寫入作業完成才能繼續，這種做法可能會導致交易速度變慢。

備份排程

在多數環境中，備份作業通常會排定每週執行一次。以下是典型的每週備份排程：

  • 週日：完整備份
  • 週一、週二：備份
  • 星期三：差異備份
  • 週四、週五：增量備份
  • 週六：差異備份

按照這個一般時間表，如要進行為期一週的滾動式復原，最多需要三個完整備份的儲存空間，加上必要的增量或差異備份。這種方法支援復原週日完整備份期間發生的故障，且資料庫復原作業必須延伸至備份開始前的上週日。

如要盡量縮短 RTO，並提高 RPO，其他資料庫可以持續復原模式運作。這項作業包括重播備份，以及透過封存和重播新的 WAL 檔案，持續更新次要環境。實際的 RPO (反映潛在的資料遺失) 取決於交易頻率、WAL 檔案大小，以及是否使用 WAL 串流。

在非 Kubernetes 環境中還原

對於非 Kubernetes 部署作業，如要還原 AlloyDB Omni 資料庫，請停止 Docker 容器，然後還原資料，或是將資料還原至其他位置，並使用還原的資料啟動新的 Docker 執行個體。容器重新啟動後，即可存取含有還原資料的資料庫。

如要進一步瞭解復原選項，請參閱「使用 pgBackRest 還原 AlloyDB Omni 叢集」和「使用 Barman 還原 AlloyDB Omni 叢集」。

使用 Operator 在 Kubernetes 中還原

如要在 Kubernetes 中還原資料庫，運算子可從具名備份或時間點 (PIT) 複製作業，將資料復原至相同的 Kubernetes 叢集和命名空間。如要將資料庫複製到其他 Kubernetes 叢集，請使用 pgBackRest。詳情請參閱「在 Kubernetes 中備份及還原」和「從 Kubernetes 備份複製資料庫叢集總覽」。

實作

選擇可用性參考架構時，請留意下列優點、限制和替代方案。

優點

  • 易於使用和管理，適合 RTO/RPO 寬鬆的非關鍵資料庫。
  • 幾乎不需要額外硬體
  • 完整的災難復原計畫一律需要備份
  • 可復原至復原期限內的任何時間點

限制

  • 儲存空間需求可能大於資料庫本身，視保留期限而定。
  • 復原速度可能較慢，RTO 可能較高。
  • 可能會遺失部分資料，具體取決於資料庫故障後，目前 WAL 資料的可用性，這可能會對 RPO 造成負面影響。

替代方案

  • 建議您考慮採用進階或進階可用性架構，以提升可用性和災難復原選項。

後續步驟