Postgresql中PG_REWIND有什么用

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

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

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

我們看看pg_rewind能幫我們什么

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

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

1  full_page_writes = on

2  wal_log_hints = on

3   hot_standby = on

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

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

1  使用文件系統(tǒng)的方式進(jìn)行拷貝

2 使用libpq 建立連接的方式將數(shù)據(jù)進(jìn)行拷貝

在拷貝數(shù)據(jù)文件的以外還需要拷貝事務(wù)提交的文件，pg_xact 以及配置文件等等。生成backup label 文件，并且指定開始要恢復(fù)的 wal 日志點(diǎn)，并應(yīng)用恢復(fù)點(diǎn)以后的日志，并且還要刷新 pg_control 文件（在設(shè)置了檢查點(diǎn)并刷新日志之后，檢查點(diǎn)的位置將保存在文件pg_control中）,最后執(zhí)行initdb -S 將數(shù)據(jù)刷入到磁盤后，關(guān)閉。

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

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

而關(guān)于bakcup label 其中包含了check point ，而后續(xù)的復(fù)制也是要依靠這個check point 點(diǎn) 目的集群就可以不斷應(yīng)用源集群從CHECKPOINT LOCATION 之后的WAL 日志。

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

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

通過pg_basebackup 進(jìn)行數(shù)據(jù)同步后，在 192.168.198.120 上在進(jìn)行相關(guān)的一些建庫，曾表，插入數(shù)據(jù)的事情，看看PG_REWIND 是否可以進(jìn)行相關(guān)的數(shù)據(jù)同步

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

1 下面的兩個服務(wù)器的數(shù)據(jù)已經(jīng)是一致的，通過pg_basebackup 進(jìn)行的復(fù)制

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

4  我們在176上進(jìn)行創(chuàng)建一個pg_rewind庫的操作，此時 兩個庫已經(jīng)數(shù)據(jù)不一致了

最后在120 上執(zhí)行 

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

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

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

首先我們要確認(rèn)幾點(diǎn)，在達(dá)到共識的基礎(chǔ)上才能繼續(xù)下面的工作

1 即使是數(shù)據(jù)同步，也必須是在之前兩個節(jié)點(diǎn)之間的關(guān)系是主從關(guān)系，或者至少是有關(guān)系，如果兩個節(jié)點(diǎn)之間沒有任何關(guān)系，則這個工作是沒有辦法做的。

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

測試1 ：

進(jìn)行數(shù)據(jù)同步，然后將從庫關(guān)閉，將recover.conf 變?yōu)?recover.done，然后重啟動從庫，在關(guān)閉，變更主庫的數(shù)據(jù)，使用pg_rewind進(jìn)行數(shù)據(jù)同步

結(jié)果失敗，通過失敗可以證明，如果主從失敗后，想直接通過提升當(dāng)前從庫的方法，在通過 pg_rewind 進(jìn)行數(shù)據(jù)同步的想法可以涼快去了

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

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

 所以相關(guān)的pg_wal 文件也要留存好，最好是有archive 來做數(shù)據(jù)恢復(fù)的后盾。

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