Postgresql Repmgr級聯復制及PostgreSQL 故障轉移是怎樣的

Postgresql Repmgr級聯復制及PostgreSQL 故障轉移是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

首先我們已經有兩臺機器，在repmgr 的管理中，從圖中可以看到 110 ，111 兩臺機器已經在 repmgr 的管理中

我們安裝另外一臺 postgresql 的機器 112 并且安裝 repmgr 軟件。

注意不要進行數據的初始化，repmgr 的機器需要復制的機器的指定的數據目錄必須為空。

repmgr -h 192.168.198.111 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --upstream-node-id=2 --verbose

192.168.198.111 是從庫，而復制直接是從從庫進行復制，而不是主庫。

開始將機器的信息加入到集群中這里首先需要的就是編輯好 repmgr.conf

具體如何編譯，請參見前幾天的 repmgr 的安裝的文字內容。這里就不重復了

repmgr -f /etc/repmgr.conf standby register --upstream-node-id=2 

命令里面的 --upstream-node-id =2  指的是數據的初始復制是來自于 從節點而從節點的 node_id  是 2 ，之后的數據復制還是來自于從庫而不是主庫

命令執行完畢后，可以在主機中找到新加入的節點信息。

我們下邊可以來驗證

select * from pg_stat_replication

通過執行語句在 110 ，111 上

在 110

在 111

相關的級聯復制就OK 了。

而一個數據庫系統的failover 其實是評判一個數據庫是否靠譜的一個重要的指標。

PostgreSQL  數據庫本身是可以進行 failover 切換的。在repmgr中我們可以通過見證服務器來做這件事。

1 首先將剛才的112 節點 脫離目前的集群

直接在 112 上執行命令

 repmgr standby unregister -f /etc/repmgr.conf 

節點會直接在 110 111上的注冊信息進行清除，但清除注冊信息，不會將復制進行清除，如有必要還需要斷掉 111 到 112 之間的復制連接。（如何停止復制，請百度或翻一下之前寫過的關于復制的文字）

112 上停止復制后，停機，將原來的 /pgdata/data 下的數據清空

 重新初始化數據庫

initdb -D /pgdata/data

啟動數據庫

pg_ctl -D /pgdata/data start

然后需要做以下工作，確認112 與其他111 110 兩臺服務器 SSH 免密登錄 賬號以啟動 pg數據庫的賬號為免密對象

配置好 repmgr.conf 文件，并且對pg_hba.conf 文件進行修改，保證見證服務器上的repmgr 賬號登錄主機和從庫都是OK 的

 repmgr -f /etc/repmgr.conf witness register -h 192.168.198.110  -d repmgr -U repmgr

執行上面的命令對112 注冊witness 見證服務器

然后在112上查看相關的信息是否正確

可以從圖中看到 112已經被注冊為見證服務器

基本上我們的環境就搭建完畢了，下面需要實現的當主機DOWN 掉后，從庫自動升級為主庫的功能。

需要repmgr 的兩點功能

1  監控功能，postgresql 服務狀態

2  通過監控狀態，觸發腳本，進行從庫轉為主庫的工作

這里我們要借助repmgr 中的監控程序 repmgrd 守護程序來對整體的集群進行一個監控。首先repmgrd守護程序需要對 /etc/repmgr.conf 中關于repmgrd 的設置進行相關配置。

下圖是配置的選擇項和相關的配置值

failover=automatic            

priority=100                          

connection_check_type=ping          

#reconnect_attempts=6                   

#reconnect_interval=10                 

promote_command=repmgr standby promote -f /etc/repmgr.conf

follow_command=repmgr standby follow -f /etc/repmgr.conf -W --upstream-node-id=%n

在配置完畢后，就可以在 111 節點運行

repmgrd -f /etc/repmgr.conf --verbose --monitoring-history

在 111 節點運行 監控后，我們關掉 110 節點的 PG 服務，監控馬上就開始反應，在嘗試6次重新連接到 主節點失敗后，開始進行從庫 升級的操作

我們在從庫和見證服務器可以運行相關查看集群狀態的命令，可以看到111已經變為了主庫。

repmgr 作為FAILOVER 以及 switch over  standby to primary 的軟件，其功能是強大的，完全滿足企業或互聯網企業在高可用中使用，輔助以一些腳本，就可以做到 MHA 一樣的效果，或更好。

PG 有了repmgr 第三方軟件的支持，如虎添翼。

看完上述內容，你們掌握Postgresql Repmgr級聯復制及PostgreSQL 故障轉移是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！