Postgresql中PG_REWIND有什么用

這篇文章主要介紹了Postgresql中PG_REWIND有什么用，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

PostgreSQL 在操作的過程中，如果利用物理復制的過程中，另一臺從庫，或者主庫由于某些原因，不再與主庫同步，或者主庫crash 起不來了，怎么辦，如果在利用現在的主庫或備庫，弄出一個 twins 。 

其實PG 早就想到這個問題了，PG有一個獨特的命令 pg_rewind 可以幫助你，再造一個你。

我們看看pg_rewind能幫我們什么

pg_rewind 的工作原理有點類似rsync，它可以無縫的讀取源目錄與目的目錄之間不同的數據塊，而重復的數據塊將不再被讀取。這樣的方式其實對于上面的問題是一個好的解決方案，因為如果主從復制，任何一方壞了，使用PG_REWIND 可以快速將你認為的數據完全的一方的數據同步到另一方，而不用做全量復制，這樣最大的好處就是節省了時間。

當然如果大概率知道checksum的（包括MYSQL的binlog checksum ）大多可以想到，怎么知道這兩邊的數據是否一致，必須的校驗塊，postgresql 如果要使用pg_rewind 功能需要你做以下的一些設置

1  full_page_writes = on

2  wal_log_hints = on

3   hot_standby = on

4  如果你在初始化數據庫集群（postgresql 單機也叫數據庫集群，別和真正的集群的含義搞混）做了data checksum 也是可以的。  

其主要的工作原理，在目的集群中對比源，與目的端之間的不同點，就是什么時候兩個服務器之間的數據開始不同步的。通過知道這些不同點開始進行

1  使用文件系統的方式進行拷貝

2 使用libpq 建立連接的方式將數據進行拷貝

在拷貝數據文件的以外還需要拷貝事務提交的文件，pg_xact 以及配置文件等等。生成backup label 文件，并且指定開始要恢復的 wal 日志點，并應用恢復點以后的日志，并且還要刷新 pg_control 文件（在設置了檢查點并刷新日志之后，檢查點的位置將保存在文件pg_control中）,最后執行initdb -S 將數據刷入到磁盤后，關閉。

問題1 ，PG_REWIND 怎么識別兩臺PG 是曾經為primary 和 standby的管理

其實就是通過 database system identifier 來鑒別，同樣的主從的 database system identifier 的編碼是一致的。同時也要看version 與 catalog version number 是否一致。

而關于bakcup label 其中包含了check point ，而后續的復制也是要依靠這個check point 點 目的集群就可以不斷應用源集群從CHECKPOINT LOCATION 之后的WAL 日志。

當然其中的原理不光如此，下面就開始做一個實驗看看pg_rewind的強大的功能。

首先下面有兩臺PG ， 192.168.198.120 主庫  192.168.198.176 從庫

通過pg_basebackup 進行數據同步后，在 192.168.198.120 上在進行相關的一些建庫，曾表，插入數據的事情，看看PG_REWIND 是否可以進行相關的數據同步

pg_basebackup 命令就不在講了，默認大家都會了，不會的可以百度，或者看我之前的關于這方面的東西。

1 下面的兩個服務器的數據已經是一致的，通過pg_basebackup 進行的復制

2  對176 進行promote 操作，模擬主庫失效，從庫接替主庫，此時主庫和從庫之間不再有任何關系 （需要修改176 的 postgresql 的監聽地址，這點是基礎就不再提了）

4  我們在176上進行創建一個pg_rewind庫的操作，此時 兩個庫已經數據不一致了

最后在120 上執行 

 pg_rewind --target-pgdata=/pgdata/data  --source-server='host=192.168.198.176 port=5432 user=repl dbname=postgres password=repl' -P --debug

將數據追齊后，修改120 的配置文件，模擬失效的主庫和已經提升為主庫的“從庫” 數據已經一致了

到這里本來就完事了，但實際上有些評論說pg_rewind 是可以做數據同步的，我是比較感興趣的，到底 pg_rewind 可不可以做數據同步。

首先我們要確認幾點，在達到共識的基礎上才能繼續下面的工作

1 即使是數據同步，也必須是在之前兩個節點之間的關系是主從關系，或者至少是有關系，如果兩個節點之間沒有任何關系，則這個工作是沒有辦法做的。

2 數據同步是否需要 promote 操作作為前提，或者直接去修改 recovery.conf 文件

測試1 ：

進行數據同步，然后將從庫關閉，將recover.conf 變為 recover.done，然后重啟動從庫，在關閉，變更主庫的數據，使用pg_rewind進行數據同步

結果失敗，通過失敗可以證明，如果主從失敗后，想直接通過提升當前從庫的方法，在通過 pg_rewind 進行數據同步的想法可以涼快去了

測試2  同步長時間的主庫已經和原來的從庫（從庫已經提升為主庫）的數據是否可行，這里的長時間其實也是看數據量，下面的情況就是報找不到pg_wal  文件，這邊可以嘗試從原來的從庫上拷貝缺少的pg_wal 或者開啟 archive 等方式保證你的pg_wal 是充足的。

圖中源主庫報沒有00000004000000000000003F 文件，找到原來的從庫，現在的主庫將這個文件拷貝到原來的主庫，則pg_rewind 正常工作。

 所以相關的pg_wal 文件也要留存好，最好是有archive 來做數據恢復的后盾。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Postgresql中PG_REWIND有什么用”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!