如何判斷 PostgreSQL Hot Standby 是否完全鏡像？

我已經設置了 PostgreSQL 伺服器的熱備份。這一切似乎都在起作用，但我只是想確保我沒有遺漏任何東西。在/var/lib/pgsql/9.2/data/pg_log/postgresql-Wed.log我有以下內容：

LOG:  creating missing WAL directory "pg_xlog/archive_status"
cp: cannot stat `/var/lib/pgsql/9.2/wal/00000002.history': No such file or directory
LOG:  entering standby mode
cp: cannot stat `/var/lib/pgsql/9.2/wal/0000000200000031000000B4': No such file or directory
LOG:  streaming replication successfully connected to primary
LOG:  redo starts at 31/B47BFAC0
LOG:  consistent recovery state reached at 31/B73624A0
LOG:  database system is ready to accept read only connections

我擔心失去的 WAL 文件。誰能確認，只要達到一致狀態，熱備就包含了master的所有數據？

我檢查的其他所有內容都表明沒問題；例如，psql -x -c "select * from pg_stat_replication;"在 master 上執行看起來不錯，並在 master 上添加新記錄複製。我只是想確保奴隸不會遺漏任何東西。

restore_command如果您設置為類似以下範例，我認為這是正常和預期的：

restore_command = 'cp /mnt/server/archivedir/%f "%p"'

手冊說：

在啟動時，備用伺服器首先恢復存檔位置中所有可用的 WAL，呼叫restore_command. 一旦到達 WAL 的末尾並且 restore_command 失敗，它就會嘗試恢復 pg_xlog 目錄中可用的任何 WAL。如果失敗，並且已經配置了流式複制，則備用伺服器會嘗試連接到主伺服器並從存檔或 pg_xlog 中找到的最後一條有效記錄開始流式傳輸 WAL。如果失敗或未配置流複製，或者如果連接稍後斷開，則備用數據庫將返回步驟 1 並再次嘗試從存檔中恢復文件。這個從歸檔、pg_xlog 和通過流複製的重試循環繼續進行，直到伺服器停止或由觸發器文件觸發故障轉移。

restore_command因此，當您啟動備用伺服器時，您可以期望看到一個故障，因為 PostgreSQL 將繼續呼叫它（使用遞增的日誌文件名/編號）直到它失敗一次。

然後它將連接到主伺服器並開始如上所述的流式傳輸，正如您在日誌中看到的那樣：

LOG:  streaming replication successfully connected to primary

從站不能保證與主站完全同步，因為它可能與主站斷開連接。特別是，這一行：

LOG:  consistent recovery state reached at 31/B73624A0

並不是說“熱備包含master的所有數據”。但是，如果您看到它後面跟著這一行，就像您所做的那樣：

LOG:  database system is ready to accept read only connections

然後數據庫“準備就緒”可以開始作為只讀備用數據庫執行，如手冊所述：

允許熱備連接可能需要一些時間，因為伺服器在完成足夠的恢復以提供可以執行查詢的一致狀態之前不會接受連接。在此期間，嘗試連接的客戶端將被拒絕並顯示錯誤消息。

就我而言，我看到consistent recovery state reached沒有跟隨database system is ready to accept read only connections. 結果證明這是一個嵌入式腳本語言外掛 ( plpython2) 的問題，它有一個系統範圍的啟動腳本 ( sitecustomize.py)，它對 PostgreSQL 程序做了壞事（為 PostgreSQL 程序啟用faulthandler和安裝信號處理程序SIGUSR2），導致它永遠不會進入熱待機模式.

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