recovery.conf文件詳解

 簡介

在恢復過程中，用戶可以通過使用recovery.conf文件來指定恢復的各個參數，如下：

• 歸檔恢復設置

  • restore_command：用於獲取一個已歸檔段的XLOG日志文件的命令
  • archive_cleanup_command：清除不在需要的XLOG日志文件的命令
  • recovery_end_command：歸檔恢復結束后執行的命令

• 恢復目標設置（默認情況下，數據庫將會一直恢復到 WAL 日志的末尾）

  • recovery_target = ’immediate’：在從一個在線備 份中恢復時，這意味着備份結束的那個點
  • recovery_target_name (string)：這個參數指定(pg_create_restore_point()所創建)的已命名的恢復點,將恢復到該恢復點
  • recovery_target_time (timestamp)：這個參數指定恢復到的時間戳
  • recovery_target_xid (string)：這個參數指定恢復到的事務 ID
  • recovery_target_inclusive (boolean)：指定是否在指定的恢復目標之后停止(true)，或者在恢復目標之前停止 (false)；適用於recovery_target_time或者recovery_target_xid被指定的情況；這個設置分別控制事務是否有准確的目標提交時間或 ID 是否將被包括在該恢復中；默認值為 true
  • recovery_target_timeline (string)：指定恢復到一個特定的時間線
  • recovery_target_action (enum)：指定在達到恢復目標時服務器應該立刻采取的動作，包括pause（暫停）、promote（接受連接）、shutdown（停止服務器），其中pause為默認動作

• 備庫參數設置

  • standby_mode(boolean)：為on表示作為一個備庫，否則不為備庫
  • primary_conninfo (string)：指定備庫連接主庫的連接字符串
  • primary_slot_name (string)：通過流復制指定主庫的一個復制槽來復制主庫數據，如果沒有設置primary_conninfo，則此參數無效
  • trigger_file (string)：指定一個觸發器文件，該文件存在可以結束備庫的恢復，即升級備庫為一個獨立的主庫
  • recovery_min_apply_delay (integer)：這個參數允許將恢復延遲一段固定的時間，如果沒有指定單位則以毫秒為單位。

如果recovery.conf中同時指定了recoveryTargetXid、recoveryTargetName、recoveryTargetTime時，PostgreSQL會按照RECOVERY_TARGET_XID> RECOVERY_TARGET_NAME > RECOVERY_TARGET_TIME的優先級來獲取最終的目標恢復位點。

如果在recovery.conf指定recovery_targetTimeLine為latest，則可以基於當前TimeLineID為起點尋找最新時間線：

• 尋找當前TimeLineID的時間線歷史文件“XXX.history”，如果存在則繼續尋找，否則錯誤退出
• TimeLineID是線性增長的，將當前TimeLineID自增1尋找是否存在時間線歷史文件，直到不存在對應的時間線歷史文件為止，即可找到最新的時間線。

 

歸檔恢復設置

 

restore_command （ string ）
要執行以檢索WAL文件系列的歸檔段的本地shell命令。歸檔恢復需要此參數，但流復制可選。字符串中的任何 %f 都將替換為要從歸檔中檢索的文件的名稱，並且任何 %p 都將替換為服務器上的復制目標路徑名。 （路徑名相對於當前工作目錄，即 集群 的數據目錄。）任何 %r 都將替換為包含最后一個有效重新啟動點的文件的名稱。這是必須保留以允許還原可重新啟動的最早文件，因此可以使用此信息將存檔截斷為支持從當前還原重新啟動所需的最小值。 %r 通常僅用於熱備份配置（請參閱 Section 26.2 ）。寫 %% 以嵌入實際的 % 字符。
僅當命令成功時，命令才能返回零退出狀態。將要求該命令提供存檔中不存在的文件名;當問到這個問題時，它必須返回非零值。例子：


restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
一個例外是，如果命令被一個信號（SIGTERM除外，它用作數據庫服務器關閉的一部分）或shell的錯誤（例如命令未找到）終止，則恢復將中止，服務器將沒有啟動。

archive_cleanup_command （ string ）
此可選參數指定將在每個重新啟動點執行的shell命令。 archive_cleanup_command 的目的是提供一種機制，用於清理備用服務器不再需要的舊存檔WAL文件。任何 %r 都將替換為包含最后一個有效重新啟動點的文件的名稱。這是必須保留的最早文件，以允許恢復可重新啟動，因此可以安全地刪除早於 %r 的所有文件。此信息可用於將存檔截斷為支持從當前還原重新啟動所需的最小值。 pg_archivecleanup 模塊通常在 archive_cleanup_command 中用於單待機配置，例如：

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
但請注意，如果多個備用服務器從同一歸檔目錄還原，則需要確保在任何服務器不再需要WAL文件之前不要刪除它們。 archive_cleanup_command 通常用於熱備份配置（請參閱 Section 26.2 ）。寫 %% 以在命令中嵌入實際的 % 字符。

如果該命令返回非零退出狀態，則將寫入警告日志消息。例外情況是，如果命令由shell發出信號或錯誤（例如未找到命令），則會引發致命錯誤。

recovery_end_command （ string ）
此參數指定僅在恢復結束時執行一次的shell命令。此參數是可選的。 recovery_end_command 的目的是提供復制或恢復后清理的機制。任何 %r 都將替換為文件名包含最后一個有效的重啟點，如 archive_cleanup_command 。
如果該命令返回非零退出狀態，則將寫入警告日志消息，並且數據庫仍將繼續啟動。例外情況是，如果命令由shell發出信號或錯誤（例如未找到命令），則數據庫將不會繼續啟動。

 

恢復目標設置

默認情況下，恢復將恢復到WAL日志的末尾。以下參數可用於指定較早的停止點。最多可以使用 recovery_target ， recovery_target_lsn ， recovery_target_name ， recovery_target_time 或 recovery_target_xid 中的一個;如果在配置文件中指定了多個，則將使用最后一個條目。

recovery_target = 'immediate'
此參數指定一旦達到一致狀態，即盡可能早地恢復。從在線備份恢復時，這意味着備份結束的時間點。
從技術上講，這是一個字符串參數，但 'immediate' 是當前唯一允許的值。

recovery_target_name （ string ）
此參數指定要繼續進行恢復的命名還原點（使用 pg_create_restore_point() 創建）。
recovery_target_time （ timestamp ）
此參數指定恢復將繼續執行的時間戳。精確的停止點也受 recovery_target_inclusive 的影響。
recovery_target_xid （ string ）
此參數指定將繼續進行恢復的事務ID。請記住，雖然事務ID在事務開始時按順序分配，但事務可以以不同的數字順序完成。將要恢復的事務是在指定事務之前（並且可選地包括）提交的事務。精確的停止點也受 recovery_target_inclusive 的影響。
recovery_target_lsn （ pg_lsn ）
此參數指定要繼續進行恢復的預寫日志位置的LSN。精確的停止點也受 recovery_target_inclusive 的影響。使用系統數據類型 pg_lsn 解析此參數。
以下選項進一步指定了恢復目標，並影響到達目標時發生的情況：

recovery_target_inclusive （ boolean ）
指定是在指定的恢復目標（ true ）之后，還是在恢復目標（ false ）之前停止。指定 recovery_target_lsn ， recovery_target_time 或 recovery_target_xid 時適用。此設置控制分別具有確切目標WAL位置（LSN），提交時間或事務ID的事務是否將包含在恢復中。默認值為 true 。
recovery_target_timeline （ string ）
指定恢復到特定時間軸。默認設置是沿着執行基本備份時的當前時間線恢復。將此設置為 latest 將恢復到存檔中找到的最新時間軸，這在備用服務器中很有用。除此之外，您只需要在復雜的重新恢復情況下設置此參數，您需要返回到在時間點恢復后到達的狀態。有關討論，請參見 Section 25.3.5 。
recovery_target_action （ enum ）
指定達到恢復目標后服務器應采取的操作。默認值為 pause ，表示恢復將暫停。 promote 表示恢復過程將完成，服務器將開始接受連接。最后 shutdown 將在到達恢復目標后停止服務器。
pause 設置的預期用途是允許對數據庫執行查詢，以檢查此恢復目標是否是最理想的恢復點。可以使用 pg_wal_replay_resume() （參見 Table 9.81 ）恢復暫停狀態，然后恢復結束。如果此恢復目標不是所需的停止點，則關閉服務器，將恢復目標設置更改為更高的目標，然后重新啟動以繼續恢復。

shutdown 設置對於在所需的確切重播點准備好實例非常有用。該實例仍然能夠重放更多的WAL記錄（事實上，自下次啟動時的最后一個檢查點以來，它必須重放WAL記錄）。

請注意，因為 recovery_target_action 設置為 shutdown 時不會重命名 recovery.conf ，所以除非更改配置或手動刪除 recovery.conf 文件，否則任何后續啟動都將立即關閉。

如果未設置恢復目標，則此設置無效。如果未啟用 hot_standby ，則 pause 的設置將與 shutdown 相同。

 

備庫參數設置

standby_mode （ boolean ）
指定是否將PostgreSQL服務器作為備用服務器啟動。如果此參數為 on ，則在到達存檔WAL結束時服務器將不會停止恢復，但是將繼續嘗試通過使用 restore_command 和/或連接到 primary_conninfo 設置指定的主服務器來獲取新的WAL段來繼續恢復。
primary_conninfo （ string ）
指定用於備用服務器與主服務器連接的連接字符串。該字符串采用 Section 34.1.1 中描述的格式。如果此字符串中未指定任何選項，則會檢查相應的環境變量（請參閱 Section 34.14 ）。如果未設置環境變量，則使用默認值。
連接字符串應指定主服務器的主機名（或地址），以及端口號（如果它與備用服務器的默認值不同）。同時指定與主節點上具有適當特權的角色相對應的用戶名（請參閱 Section 26.2.5.1 ）。如果主要要求密碼驗證，也需要提供密碼。它可以在 primary_conninfo 字符串中提供，也可以在備用服務器上的單獨 ~/.pgpass 文件中提供（使用 replication 作為數據庫名稱）。不要在 primary_conninfo 字符串中指定數據庫名稱。

如果 standby_mode 為 off ，則此設置無效。

primary_slot_name （ string ）
（可選）指定在通過流復制連接到主節點時使用的現有復制槽，以控制上游節點上的資源刪除（請參閱 Section 26.2.6 ）。如果未設置 primary_conninfo ，則此設置無效。
trigger_file （ string ）
指定其狀態在備用數據庫中恢復恢復的觸發器文件。即使未設置此值，您仍可以使用 pg_ctl promote 升級待機狀態。如果 standby_mode 為 off ，則此設置無效。
recovery_min_apply_delay （ integer ）
默認情況下，備用服務器會盡快從主服務器恢復WAL記錄。擁有時間延遲的數據副本可能很有用，可以提供糾正數據丟失錯誤的機會。此參數允許您將恢復延遲一段固定的時間，如果未指定單位，則以毫秒為單位。例如，如果將此參數設置為 5min ，則備用數據庫將僅在備用數據庫上的系統時間超過主服務器報告的提交時間超過五分鍾時重播每個事務提交。
服務器之間的復制延遲可能超過此參數的值，在這種情況下不會添加延遲。請注意，延遲是在寫入主站的WAL時間戳和備用站上的當前時間之間計算的。由於網絡延遲或級聯復制配置而導致的傳輸延遲可能會顯着縮短實際等待時間。如果主服務器和備用服務器上的系統時鍾不同步，則可能導致恢復應用早於預期的記錄;但這不是主要問題，因為此參數的有用設置遠大於服務器之間的典型時間偏差。

僅在事務提交的WAL記錄上發生延遲。其他記錄盡可能快地重放，這不是問題，因為MVCC可見性規則確保在應用相應的提交記錄之前它們的效果不可見。

一旦恢復中的數據庫達到一致狀態，直到備用數據庫被提升或觸發，就會發生延遲。之后，備用數據庫將無需等待即可結束恢復。

此參數適用於流復制部署;但是，如果指定了參數，則在所有情況下都將遵守該參數。 hot_standby_feedback 將因使用此功能而延遲，這可能導致主人膨脹;小心使用。

警告

當 synchronous_commit 設置為 remote_apply 時，同步復制受此設置的影響;每個 COMMIT 都需要等待才能應用。