PostgreSQL中的即時恢復（PITR）

教學
PostgreSQL

時間點恢復（PITR）是 PostgreSQL 中的一個強大功能，隨著 PostgreSQL 的出現，它變得更加高效且用戶友好。它使管理員能夠將 PostgreSQL 數據庫恢復到過去的某個特定時刻。這在管理大型系統的災難恢復和大量交易負載時尤其有用。

這篇博客將探討 PITR，並讓您了解潛在的陷阱及其解決方案，以確保平穩且成功的實施。我們還將分享其主要好處，並詳細介紹 PostgreSQL 的逐步實施。

關鍵組件

實施 PITR 涉及兩個關鍵組件：

1. 基本備份

基本備份是數據庫在特定時間點的快照。它包含了恢復數據庫到其原始狀態所需的所有數據文件、配置文件和元數據。基本備份作為 PITR 的起點。

2. 日誌前寫（WAL）

WAL 文件記錄了對數據庫所做的每一個更改。這些日誌存儲了恢復數據庫到特定時間狀態所需的更改。在執行 PITR 時，您需要按順序重放 WAL 文件，以重建所需的數據庫狀態。

為什麼使用 PITR？

PITR 在幾種情況下都非常有用：

撤銷意外更改

意外操作，例如沒有 WHERE 子句的 DELETE 或 DROP 語句，可能導致重大數據丟失。使用 PITR，您可以將數據庫恢復到錯誤發生前的狀態，保留關鍵數據。

從數據損壞中恢復

應用程式 錯誤、硬體故障或磁碟損壞可能導致數據不一致。PITR 允許您恢復一個乾淨的數據庫快照並僅重播有效的變更，從而最小化停機時間和數據丟失。

為測試或除錯恢復

開發者經常需要複製生產數據庫以進行除錯或測試。PITR 使您能夠在特定時間點創建數據庫的快照，便於進行受控實驗而不影響實時數據。

災難恢復

PITR 對於災難恢復策略至關重要。在災難性的故障中，例如自然災害或網絡攻擊，您可以迅速將數據庫恢復到最後一致的狀態，確保業務連續性。

資源的高效使用

通過結合定期的基本備份和WAL文件，PITR最小化了對頻繁完整備份的需求，節省了存儲空間並減少了備份時間。PITR也是一種精確的恢復方法，允許您恢復到特定的秒數，並最小化在事件期間數據丟失的風險。它足夠靈活，可以高效處理各種恢復場景，從單個事務回滾到完整數據庫恢復。

PostgreSQL 17對PITR有什麼新功能？

PostgreSQL 17引入了幾項針對PITR的增強功能，重點關注性能、可用性和兼容性：

故障轉移槽同步

邏輯複製槽現在支持故障轉移期間的同步。這確保了在故障轉移後仍保留PITR所需的WAL，減少了手動干預。

增強的WAL壓縮

更新了WAL壓縮算法，以提高存儲效率，減少歸檔WAL所需的空間。這對於具有高事務率的大型系統特別有利。

更快的恢復速度

在WAL重放過程中的優化導致恢復時間更快，特別是對於大型數據集。

與邏輯複製的兼容性改善

PITR現在與邏輯複製設置更好地整合，讓恢復利用物理和邏輯複製的集群變得更容易。

細粒度的WAL歸檔控制

PostgreSQL 17提供了更多對WAL歸檔的控制，允許您微調保留策略以匹配恢復需求。

在PostgreSQL中執行PITR的詳細步驟

按照這些步驟設置和執行PITR。在使用PITR之前，您需要：

  • WAL歸檔：啟用並配置WAL歸檔。
  • 基本備份：使用pg_basebackup或pgBackRest進行完整的基本備份。
  • 安全存儲：確保備份和WAL文件安全存儲，最好是在異地。

1. 配置WAL歸檔

WAL歸檔對於PITR至關重要，因為它存儲了備份之間的增量變更。要配置WAL歸檔，請更新postgresql.conf文件，設置：

Shell

 

然後，在設置配置參數後，重新啟動PostgreSQL服務器：

Shell

 

使用以下命令檢查WAL歸檔的狀態：

SQL

 

檢查 pg_stat_archiver 視圖或 PostgreSQL 日誌中的任何錯誤。

2. 執行基礎備份

進行基礎備份，以作為 PITR 的起始點；使用 pg_basebackup，該命令的形式為：

Shell

 

這會創建一致的數據庫快照並確保 WAL 文件被存檔以便恢復。

3. 驗證備份完整性

使用 pg_verifybackup 來驗證備份的完整性：

Shell

 

4. 模擬故障

為了演示目的，您可以模擬一次故障。例如，意外刪除數據：

Shell

 

5. 還原基礎備份

在還原基礎備份之前，停止 PostgreSQL 伺服器：

Shell

 

然後，使用以下命令更改現有數據目錄的名稱：

Shell

 

然後，用基礎備份替換數據目錄：

Shell

 

更新數據目錄的權限：

Shell

 

6. 配置恢復

要啟用恢復模式，您首先需要在 PostgreSQL 數據目錄中創建一個 recovery.signal 文件：

Shell

 

然後，更新 postgresql.conf，添加以下參數：

Shell

 

7. 在恢復模式下啟動 PostgreSQL

使用以下命令重新啟動 PostgreSQL 伺服器：

Shell

 

監控日誌以查看恢復進度：

Shell

 

PostgreSQL 在恢復完成後會自動退出恢復模式並變為可操作狀態。

8. 驗證恢復

恢復後，驗證資料庫狀態：

SQL

 

處理潛在問題

缺失或損壞的 WAL 檔案

問題

恢復所需的 WAL 檔案缺失或損壞。

解決方案

  • 確保定期使用 pg_verifybackup 等工具驗證備份和 WAL 存檔。
  • 為 WAL 存檔使用冗餘存儲。

錯誤的恢復目標

問題

恢復在意外狀態停止。

解決方案

  • 仔細檢查 recovery_target_time、recovery_target_lsn 或 recovery_target_name。
  • 使用 pg_waldump 檢查 WAL 檔案中的目標事件。

恢復期間的性能瓶頸

問題

由於大型 WAL 檔案，恢復耗時過長。

解決方案

  • 通過增加 maintenance_work_mem 和 max_parallel_workers 來優化恢復性能。
  • 使用 WAL 壓縮來減少檔案大小。

時鐘偏差問題

問題

由於時鐘差異，恢復時間戳需要對齊。

解決方案

使用 NTP 等工具同步伺服器時鐘。

配置錯誤的 WAL 存檔

問題

不正確的 archive_command 會導致 WAL 存檔失敗。

解決方案

  • 手動測試 archive_command：cp /path/to/test_wal /path/to/wal_archive/。
  • 確保存檔目錄具有足夠的權限。

最佳實踐以實現 PITR

  1. 自動化備份：使用 工具，如 pgBackRest 或 Barman 進行計劃備份和 WAL 存檔。
  2. 監控 WAL 存檔：定期檢查 pg_stat_archiver 以發現問題。
  3. 驗證備份：始終使用 pg_verifybackup 驗證備份完整性。
  4. 測試恢復程序：定期模擬恢復場景以確保準備就緒。
  5. 保護 WAL 存檔：對於 WAL 存檔，使用安全的冗餘存儲，例如雲服務或 RAID 配置的磁碟。

結論

精確時刻恢復 (PITR) 對於維持資料庫可靠性及減少事件發生時數據損失至關重要。pgEdge 和 PostgreSQL 17 的增強功能使 PITR 更快、更有效且更易於管理，特別是對於大規模或高可用系統。

遵循本指南的步驟和最佳實踐將幫助您在 PostgreSQL 環境中有效實施和管理 PITR。定期測試和監控對於確保恢復過程在最需要時可用至關重要。

Source:
https://dzone.com/articles/point-in-time-recovery-pitr-in-postgresql