如何分析PostgreSQL WAL LOG 與時間線timeline與rejoin node錯誤

如何分析PostgreSQL WAL LOG 與時間線timeline與rejoin node錯誤，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

問題的起因是，在做repmgr 恢復的時候，經常有同學說恢復的時候， repmgr rejion node 的時候pg_rewind 會報錯，與時間線有關。（pg_rewind之前是寫過的清參閱之前的文字）

PostgreSQL 中的wal log 對于數據庫是很重要的，基本wal log 解決的問題就是在數據寫入到數據庫的時候并沒有必要非要立即寫入到存儲系統，通過wal log 及時記錄 postgresql 中所作的事情，在出現數據庫問題的時候，通過wal log 就可以將數據進行恢復。所以wal log 出現最主要的原因，（個人認為），保證數據安全性下的最大化數據庫的性能。磁盤的順序寫的性能是一定比隨即寫要好的根本決定了上面的數據庫建立的構思。

使用WAL可以顯著減少磁盤寫操作的數量，因為只需要將日志文件刷新到磁盤，以確保提交了事務，而不是事務更改的每個數據文件。日志文件是按順序寫入的，因此同步日志的成本遠遠低于刷新數據頁的成本。對于處理許多涉及數據存儲的不同部分的小事務的服務器來說尤其如此。

那時間線是什么，我們來一個直觀的東西，打開pg_wal (pg11版本)，可以看到下圖。

每次創建一個新的時間軸，PostgreSQL都會創建一個名為“.history”的“時間軸歷史”文件。時間軸歷史文件由原始時間軸歷史文件中的內容和當前時間軸的切換記錄組成。假設已啟動恢復的數據庫并切換到新的時間軸ID=5。然后將時間軸歷史文件命名為00000005.history。該文件記錄了文件分支的原因、時間軸和時間。該文件可能包含多行記錄。

通過上面的時間軸的history 可以看到每個新的history文件隨著數字的疊加，歷史記錄也是在一致添加的。

當數據庫從包含多個時間軸的歸檔中恢復時，歷史文件允許系統選擇正確的WAL文件。歷史文件也可以像WAL文件一樣歸檔到WAL歸檔目錄。歷史文件是非常小的文本文件，因此需要很少的存儲空間。如果希望通過在恢復中指定目標時間軸tli來恢復數據庫。如果希望通過在恢復中指定目標時間軸tli來恢復數據庫。conf中，程序首先查找.history文件，然后根據.history文件中記錄的時間軸分支之間的關系，查找pg_control中從startTLI到tli的所有時間軸對應的日志文件，并恢復數據庫。

而上面提到的問題，無法進行的原因有因為沒有配備 PG_REWIND必要的使用的環境，例如打開 full page  wal log hit 等等 如果使用repmgr 則必須要共享加載中也要配置repmgr 。而這些工作沒有做，造成了使用 rejoin 時的錯誤。

另外一個問題我們是不是要使用PG_REWIND 來作為rejoin的一個選項，官方的文檔上給出的命令是這樣的。我想下面這句話可以來解釋

當從級提升到新主級時，它會創建一個新的時間軸，以避免WAL名稱重疊。history文件包含關于數據庫時間軸分支的信息。恢復過程使用這些信息來確定它正在處理的時間軸。

所以使用pg_rewind 的原因也是要通過文件級別的方式來拷貝數據到原來的主，現在的從，來使數據一致，建議要使用PG_REWIND, 而使用PG_REWIND 則必須要進行 POSTGRESQL 安裝時的一系列的設置，這都是一環套一環的。 

關于如何分析PostgreSQL WAL LOG 與時間線timeline與rejoin node錯誤問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。