數據庫不可用的常見原因
在PostgreSQL復制中，由於幾個原因，主數據庫可能變得不可用。例如：
- 主節點的操作系統可能崩潰或變得無響應
- 主節點可能會失去其網絡連接
- 主節點中的PostgreSQL服務可能崩潰，停止或意外變得不可用
- 主節點中的PostgreSQL服務可以有意或無意停止
每當主服務器不可用時，備用服務器都不會自動將其自身升級為主角色。備用服務器仍繼續為只讀查詢服務-盡管數據將一直保持最新狀態，直到從主服務器接收到的最后一個LSN。任何寫操作嘗試都將失敗。
有兩種方法可以減輕這種情況：
- 備用數據庫已手動升級為主機。計划內的故障轉移或“切換”通常是這種情況
- 備用數據庫自動升為主機，由工具連續監視復制並在主數據庫不可用時采取恢復操作。repmgr就是這樣一種工具
備用數據庫自動升級為主機主要有以下挑戰：
- 如果有多個備用數據庫，repmgr如何確定將哪個數據庫升級為主數據庫？
- 對於多個備用數據庫，如果將其中一個升級為主數據庫，那么其他節點如何“跟隨它”作為新的備用數據庫？
- 如果主數據庫服務器正常運行，但由於某種原因暫時脫離網絡，該怎么辦？如果將其中一個備用數據庫升級為主要數據庫，然后原來的主要數據庫重新聯機，此時集群中就出現了2個主機（腦裂），那么如何避免出現“腦裂”情況？
repmgr提供的解決方案為提供見證節點和repmgr守護程序
完整的集群架構參考下圖：
見證節點
見證節點主要的工作是幫助備用數據庫達到法定的數量
簡單來講，備機連不上主機了，就會連接見證節點，如果也連接不上見證節點，那判斷自己網絡故障了，如果能連上見證節點，則認為主機故障，見證節點的作用類似於一個信任的網關。
守護程序repmgrd
remgrd啟動后會作為常規服務運行並持續監視集群的運行狀況。當達到與主機數據庫失去聯系的法定人數時，它將啟動故障轉移。它不僅可以自動升級備用數據庫，還可以在多節點群集中重新啟動其他備用數據庫以跟隨新的主數據庫。
如何仲裁哪台備機升主
- 每個備用數據庫檢查到主機數據庫故障后會進行重試，重試最后一次后，會去詢問其他備用數據庫。如果其它備用節點的最后一個復制的LSN或與主節點的最后一次通信的時間比當前節點的最后一個復制的LSN或最后一次通信的時間更近，則該節點不執行任何操作，並等待與主節點的通信恢復。
- 如果所有備用數據庫都看不到主數據庫，則它們將檢查見證節點是否可用。如果也無法到達見證節點，則備用服務器會假定主服務器端發生網絡中斷，因此不會繼續選擇新的主服務器
- 如果可以聯系到見證人，則備用服務器會假定主服務器已關閉，然后繼續選擇主服務器
- 然后將升級配置為“首選”主節點的節點。每個備用數據庫將重新初始化其復制，以跟隨新的主數據庫。