測試/驗證日誌傳送備份

我們最近在一個包含兩台 PostgreSQL 8.4 輔助伺服器的數據中心遭遇電源/連接中斷，這些伺服器通過日誌傳送複製遠端備份我們的兩個主伺服器。備用電源使他們保持活力，但他們在兩天多的時間裡沒有收到 WAL 文件。在我們再次恢復連接之前，兩個初選的積壓接近 3500。

當我查看~postgres/data/pg_log兩個輔助伺服器上的日誌時，我可以在目前日誌中看到，當我們重新聯機時要處理的第一個 WAL 段是在最後一個進入日誌之後的數字連續的下一個從停電開始之日起歸檔。看起來我們沒有錯過任何東西，並且在不到一天的時間內就趕上了二級。

但我想驗證這一點。最能有效緩解我的妄想症的方法是再次中斷連接，以便主節點開始緩衝 WAL 文件，將輔助電腦單獨提升為主節點，執行足夠嚴格的只讀查詢來滿足我自己對備份數據的完整性的要求，然後將輔助伺服器重新置於持續恢復模式，最後恢復連接。

那可行嗎？或者查詢的提升和處理，甚至是只讀查詢，是否會改變輔助數據庫，以至於它無法在之後恢復連續恢復？

我意識到這不會是流複製的問題，但 8.4 沒有這種能力。

在使從數據庫集群進入獨立讀寫模式後（通過內部邏輯recovery_command或在沒有 的情況下重新啟動recovery.conf），它不能輕易恢復為從數據庫。

如果可以，請使用文件系統級別的快照。這將是最簡單的方法，因為您無需複制整個數據目錄即可將集群恢復到已知狀態。

或多或少這將是測試奴隸的邏輯：

stop_postgres()
make_pgdata_filesystem_snapshot()
remove_recovery_conf()
start_postgres()
run_testing()
stop_postgres()
revert_pgdata_fs_snapshot()
start_postgres()

如果您沒有文件系統快照，您將需要整個集群的本地副本（rsync 可以很好地維護它）。唯一的缺點是使用了磁碟空間，並且需要更多時間。

rsync_pgdata_to_local_copy()
stop_postgres()
rsync_pgdata_to_local_copy()
remove_recovery_conf()
start_postgres()
run_testing()
stop_postgres()
rsync_pgdata_from_local_copy()
start_postgres()

引用自：https://dba.stackexchange.com/questions/203649