25.4. 日志傳送的替代方法 · PostgreSQL 中文文檔 9.3

# 25.4\. 日志傳送的替代方法一種替代在前節描述的內建備用模式的方法是使用`restore_command`輪詢歸檔位置。這是只能在8.4及以下版本選擇使用。在此設置`standby_mode`關閉，因為你要實現備服務器運行你自己所需的輪詢。請參考[pg_standby](#calibre_link-1620)模塊關于這類的實現。請注意在這種模式，服務器將一次應用一個WAL文件，所以如果你使用備服務器對于查詢（見熱備），在主服務器中的動作和當這個動作在備服務器中可見之間有個延遲，相應的時間用在填寫WAL文件。`archive_timeout`可以使延遲較短。還要注意你不能用這種方法結合流復制。主備用服務器上發生的操作是正常的連續歸檔和恢復任務。兩個數據庫服務器相聯系的一點是兩者共享的WAL歸檔文件：主寫入歸檔，備從歸檔讀取。必須小心，以確保從單獨的主服務器，不會混在一起或混淆WAL歸檔。如果只是備服務器操作要求，歸檔需要并不大。使松散耦合的兩個服務器一起工作簡直是奇跡，在備服務器上簡單使用`restore_command`，當詢問下一個WAL文件，等待其為主服務器可用的。在備服務器的`recovery.conf`文件指定`restore_command`。通常恢復進程將從一個WAL歸檔中請求文件，如果該文件不可用，則報告失敗。對備服務器進程來說下一個WAL文件不可用是正常的，因此備服務器進程需要等待它出現。對于在`.backup`或者`.history`文件結束不需要等待，并且返回一個非零值。等待`restore_command`可以寫為一個自定義腳本，即循環輪詢下一個WAL文件的存在。還必須有一些方法來觸發失效切換，應該中斷的`restore_command`，跳出循環，并返回備用服務器一個文件未找到錯誤。這兩端的恢復和備用服務器，然后將作為一個正常的服務器。一個合適`restore_command`的偽碼是： ``` triggered = false; while (!NextWALFileReady() && !triggered) { sleep(100000L); /* wait for ~0.1 sec */ if (CheckForExternalTrigger()) triggered = true; } if (!triggered) CopyWALFileForRecovery(); ``` 在[pg_standby](#calibre_link-1620)模塊中提供一個等待`restore_command`的實際例子。應該用來作為參考如何正確地貫徹執行上述邏輯。它也可以擴展需要，以支持特定的配置和環境。觸發失效切換的方法是規劃和設計的一個重要組成部分。一個潛在的選項是`restore_command`命令。每個WAL文件執行一次，但是運行`restore_command`的進程對于每個文件創建和消亡的，所以沒有守護進程或服務器進程和信號或不能使用的信號處理。因此，`restore_command`不適合觸發失效切換。使用簡單超時機制可能的，尤其如果與已知的`archive_timeout`在主服務器上配合設置使用。盡管，這比較容易出錯，因為網絡問題或繁忙的主服務器可能有足夠的啟動失效切換。如果可以安排，通報機制如顯式創建一個觸發器文件是理想的。 ## 25.4.1\. 實施配置備用服務器，使用這種替代方法簡短步驟如下。對于每一步的細節，請參閱前面的章節。 1. 建立主備系統盡可能接近相同，包括兩個PostgreSQL副本在相同版本級別。 2. 設置從主服務器上連續歸檔到備服務器WAL歸檔目錄。確保在主服務器上相應的設置[archive_mode](#calibre_link-1038), [archive_command](#calibre_link-467)和[archive_timeout](#calibre_link-468)。 (參閱[Section 24.3.1](#calibre_link-1435))。 3. 做一個主服務器的基準備份(參閱[Section 24.3.2](#calibre_link-1632))，在備服務器上加載這個數據。 4. 在備服務器上從一個本地的WAL歸檔開始恢復，如前所述等待使用`recovery.conf`所指定的`restore_command`。（請參閱[Section 24.3.4](#calibre_link-1634)）。恢復對WAL歸檔做只讀處理，所以一旦在WAL的文件已被復制到備用系統，就可以在同一時間復制到磁帶，因為正通過備用數據庫服務器讀取。因此，運行高可用性的備用服務器可以同時作為文件存儲長遠的災難恢復目的做處理。出于測試目的，它是可以在同一系統上運行的主備服務器。沒提供任何值得改進服務器的健壯性，也不會描述為HA。 ## 25.4.2\. 基于記錄的日志傳送使用這種替代方法也有可能實現基于記錄的日志傳送，盡管這需要定制開發，一個完整的WAL文件傳送之后變化只為熱備查詢可見。一個外部程序可以調用`pg_xlogfile_name_offset()`（參閱[Section 9.26](#calibre_link-1334)）這個函數用來找出文件名和當前WAL結尾的準確字節偏移。然后，可以直接訪問WAL文件，并從WAL的上次已知的結尾到當前結束數據復制數據到備用服務器。用這種方法，數據丟失窗口是復制程序的輪詢周期時間，其可以非常小，并沒有迫使部分使用的段文件要歸檔的帶寬浪費。請注意備服務器上的`restore_command`腳本只能處理完整的WAL文件，所以通常的增量備份數據到備服務器不可用。只有在主服務器死掉— 在允許它到來前，最后一部分WAL文件送到備服務器。在這個進程中的正確實現，需要`restore_command`腳本與數據復制程序協作。 PostgreSQL9.0版本開始，你可以使用流復制達到事半功倍的效果（請參閱[Section 25.2.5](#calibre_link-1048)）。