轉載自：https://www.modb.pro/db/11339 《輕量級流複製管理工具Repmgr高可用功能的優化》

Repmgr功能概述

Repmgr作為由第二象限開發的一款流複製管理工具，具有非常輕量級的使用特性。具體表現為：

* 配置操作簡單，可一鍵式完成相關部署操作；
* 支援Auto Failover和Manual Switchover；
* 分散式管理叢集節點，易擴充套件，可線上增刪叢集節點；
* Repmgr流複製管理系統有repmgr和repmgrd兩個命令。
* 其中repmgr命令實現對叢集節點的管理，如註冊主/備節點、Clone節點，Promote節點，Follow節點以及Switchover操作等；
* repmgrd命令用來啟動repmgr系統的守護程序，用以對叢集節點的監控。
 

下圖是Repmgr實現架構圖。

Repmgr流複製管理工具對叢集節點的管理是基於一個分散式的管理系統。每個節點都有自己的repmgr.conf配置檔案，用來記錄本節點的ID,節點名稱，連線資訊，資料庫PGDATA目錄等配置引數。在配置好這些引數後，就可以通過repmgr命令實現對叢集節點的“一鍵式”部署。

主節點：

1. 配置好相關引數
2. 啟動資料庫
3. 利用“repmgr primary register”命令實現對主節點的註冊。
（該註冊的目的是把配置檔案的一些主要引數寫到元資料表中，以便repmgr系統對叢集節點的識別操作等。）
4. 啟動repmgrd守護程序。

備節點：

1. 配置好相關引數
2. 利用“repmgr standby clone”命令對主節點進行物理拷貝。
3. 啟動資料庫
4. 利用“repmgr standby register”命令實現對備節點的註冊。
5. 啟動repmgrd守護程序。

部署完成後，每個節點都有自己的元資料表，記錄所有叢集節點的資訊；每個節點都有自己的repmgrd守護程序來監控節點資料庫狀態。其中主節點守護程序主要用來監控本節點資料庫服務狀態，備節點守護程序主要用來監控主節點和本節點資料庫服務狀態。在發生Auto Failover時，備節點在嘗試N次連線主節點失敗後，repmgrd會在所有備節點中選舉一個候選備節點（選舉機制參考以下Tips）提升為新主節點，然後其他備節點去Follow到該新主上，至此，形成一個新的叢集狀態。

Tips：

Repmgr選舉候選備節點會以以下順序選舉：LSN ， Priority， Node_ID。
系統會先選舉一個LSN比較大者作為候選備節點；如LSN一樣，會根據Priority優先順序進行比較，該優先順序是在配置檔案中進行引數配置；如優先順序也一樣，會比較節點的Node ID，小者會優先選舉。

Repmgr高可用功能優化
Repmgr作為流複製管理工具，在高可用方面還有一些不足之處：

內部沒有提供對Virtual IP的管理和支援
高可用場景的完善優化

1. Virtual IP的支援

Virtual IP作為應用程式連線叢集的“紐帶”，是需要繫結在主節點上的，且在叢集發生failover時，能夠“漂移”到新主節點上。
經過優化後的Repmgr可以提供以下對Virtual IP的支援：
註冊主節點時，會繫結Virtual IP
Failover時，原主解綁Virtual IP，新主重新繫結
叢集節點重啟時，會識別主接點然後繫結Virtual IP
Switchover時，Virtual IP會隨主節點進行漂移

2. 高可用場景的完善優化

針對主節點出現故障，應用程式不能連線資料庫服務，可以分為以下三種場景：
網路斷開
系統掉電
外部儲存掉線

<1> 網路斷開
當叢集主節點網路斷開（網線被拔掉或者網絡卡壞掉）後， Repmgr原來的機制是：備節點會有N次（配置引數）嘗試機會去連線主節點，如果N次連線還是不成功，則Repmgr系統會認為主節點出現故障，開始進行failover。failover過程中，系統會選舉一個備節點提升為新主節點，該過程中，Virtual IP也會漂移到新主上去，其他備節點隨後去Follow該新主節點。
但是現在需要注意的問題是：如果原來主節點網路恢復後，則它會以一個“非法”的主節點繼續存在叢集中。

針對該問題對Repmgr進行優化後:
在完成failover過程後，如果原來主節點網路恢復，則repmgrd守護程序會對原來主節點進行降級成備節點，然後重新“node rejoin”到叢集裡，即原來主節點會變成備節點角色重新加入叢集，保證在Failover後，繼續維持叢集的節點數量。

<2> 系統掉電
所謂系統掉電的高可用就是指系統在掉電，然後再上電後，能繼續維持叢集所有節點的正常狀態。這部分的實現，除了Repmgr流複製管理系統，還需要依賴資料庫的啟動指令碼。
當主節點掉電後，failover過程同斷網一樣，備節點在嘗試N次連線主節點後沒有成功時，Repmgr系統選舉出一個備節點進行提升為新主節點，Virtual IP同樣漂移到該新主節點上，隨後其他備節點follow到新主節點上。
當Failover過程完成後，重新啟動原主節點系統，系統會依次啟動資料庫服務，repmgrd守護程序，接下來repmgrd守護程序同斷網場景一樣，對原主節點降級成備節點，然後重新加入到叢集中去。
當然，備節點掉電後再上電，同樣重新加入叢集裡去。
除了單個節點掉電，還有整個叢集節點全部掉電的場景（其實這種場景在有些情況下出現的概率比單個節點掉電的概率還要高）。
整個叢集都掉電後，不會發生failover過程。此時只需要對叢集各個節點重新上電來恢復原來的叢集狀態。在恢復過程中，資料庫系統依靠啟動指令碼會依次恢復資料庫服務和repmgrd守護程序，在判斷出主節點後，會重新繫結Virtual IP。最後恢復為掉電前的叢集狀態。需要注意的是，由於repmgrd是依賴資料庫服務啟動的，特別是備節點的repmgrd需要依賴主節點的資料庫服務。所以按邏輯，需要先啟動主節點系統，然後再啟動備節點系統。但經過優化後，可以按任意節點順序啟動恢復整個叢集狀態。

<3> 外部儲存掉線

該場景應用在將資料庫資料儲存在掛載的外部儲存上。當外部儲存光纖掉線後，repmgrd守護程序通過檢測$PGDATA目錄出現故障（只讀或寫hang住）後，會先停掉當前資料庫服務（$PGDATA出現問題後，資料庫服務依然處於活動狀態），以為failover過程做準備。當資料庫服務停掉後，failover過程就如掉電等過程一樣。
當儲存重新掛載或重啟系統恢復正常後，原主節點同樣會降級成備節點重新加入叢集中去。
同異步轉換場景的完善
在一主一備叢集場景中，把備節點設定為同步備節點能夠保證資料的安全可靠性，但是如果備節點如果出現斷網或服務停掉的問題，則主節點寫操作會hang住。為了解決上述問題，保證業務的連續性，增加了同異步轉換的功能。

同步轉非同步：
在備節點出現斷網或停服務後，主節點通過walsend程序的狀態判斷同步備節點是否還正常（如果是斷網問題，主節點會等待wal_sender_timeout之後做出判斷），在判斷備節點出現問題後，repmgrd會再預留timeout時間檢測備節點狀態。超過timeout備節點沒有恢復正常，主節點會通過修改synchronous_standby_names並reload，來完成從同步模式轉換為非同步模式的過程。

非同步轉同步：
在同步轉非同步後，如果備節點又恢復正常了，此時會進行恢復為原來的同步模式。具體實現為：在備節點恢復正常後，在catchup主節點的LSN延遲達到一個比較小的值時，主節點同樣通過修改synchronous_standby_names引數並reload，這樣主節點就完成了從非同步模式轉換為同步模式的過程。