資料庫PostrageSQL 恢復目標設定

2021-10-12 19:53:22 字數 1982 閱讀 5463

預設情況下,恢復將會一直恢復到 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_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_lsnrecovery_target_time或者recovery_target_xid被指定的情況。 這個設定分別控制事務是否有準確的目標wal位置(lan)、提交時間或事務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)繼續,這會讓恢復終結。如果這個恢復目標不是想要的停止點,那麼關閉伺服器,將恢復目標設定改為乙個稍後的目標並且重啟以繼續恢復。

注意由於在recovery_target_action被設定為shutdown時,recovery.conf將不會被重新命名,任何後續的啟動都將會以立刻關閉為終結,除非該配置被改變或者recovery.conf檔案被手工移除。

如果沒有設定恢復目標,這個設定沒有效果。如果沒有啟用hot_standby,pause設定的動作將和shutdown一樣。

資料庫PostrageSQL 架構

邏輯複製從拷貝發布者資料庫上的資料庫快照開始。拷貝一旦完成,發布者上的更改會在它們發生時實時傳送給訂閱者。訂閱者按照資料在發布者上被提交的順序應用資料,這樣任意單一訂閱中的publication的事務一致性才能得到保證。訂閱者資料庫上的應用程序總是將session replication role設...

資料庫PostrageSQL 啟動資料庫伺服器

在任何人可以訪問資料庫前,你必須啟動資料庫伺服器。資料庫伺服器程式是postgres,它必須知道在 能找到它要用的資料。這是用 d選項實現的。因此,啟動伺服器最簡單的方法是 postgres d usr local pgsql data這將把伺服器放在前台執行。這個步驟同樣必須以postgresql...

資料庫PostrageSQL 鎖管理

deadlock timeout integer 這是進行死鎖檢測之前在乙個鎖上等待的總時間 以毫秒計 死鎖檢測相對昂貴,因此伺服器不會在每次等待鎖時都執行這個它。我們樂觀地假設在生產應用中死鎖是不常出現的,並且只在開始檢測死鎖之前等待一會兒。增加這個值就減少了浪費在無用的死鎖檢測上的時間,但是減慢...