接上期說，(沒看上期的，還是先看上期，要不從這看是看不懂的)

那到底這個手動轉換的過程是如何的，這個要搞一搞清楚

repmgr -f /etc/repmgr.conf standby switchover -U repmgr? --verbose

1 步 根據執行地的repmgr 數據庫中的記錄，開始找到那個是當前的主節點，因為你是在從庫執行的

2 步 發現主節點，并且找到其node ID

3 步連接到主節點通過SSH 協議

4 檢測當前的archive 文件

5 檢測主從之間的數據差距，通過wallog 來判斷

6 檢測沒有問題，關閉主節點，如果還有沒有checkpoint的，就等待checkpoint

7 開始執行 -m fast sotp 命令，快速關閉pg 主庫

8 開始等待關閉，時間為1分鐘，每秒偵測一次到底關沒有關 (可以調節)

9 開始對從庫 promote ?執行promote 命令

10 開始檢查從庫是否promote 成功? 時間1 分鐘

11 將原來的主庫重新加入，對比兩個節點之間的日志差距

12 原主節點變更為從節點

任務成功

那問題來了，如果要是這段操作不成功呢，MHA 也沒有百分之百成功的，也有失誤的時候，如何補救。

下面繼續，

遇到的問題

1 雖然切換成功，但原主庫并沒有關閉，demotion失敗

解決方法

1 關閉原主庫(用任何方法都可以)，如果運維自動化，可以寫腳本，KILL

2 打開主庫，然后使用命令將其驅逐出 repmgr 集群

使用命令

repmgr standby unregister -f /etc/repmgr.conf

將降級為standby的從庫從集群中注銷

3 關閉分離的從庫

4 清理數據目錄

5 重新使用?

?repmgr -h 192.168.198.22 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone?

命令將進行從庫的clone

6 更改 postgresql.conf listen 地址

7 啟動從庫

8 重新注冊從庫??

repmgr -f /etc/repmgr.conf standby register

一切正常，數據庫集群完璧歸趙。

手動的切換的問題，我們告一段落，下面是怎么能自動切換的問題，怎么配置的過程先不廢話，先看效果，估計要講清這個系列的問題，是要幾期的

192.168.198.21? primary postgresql

192.168.198.22? standby postgresql

現在我要停止 192.168.198.21 的postgresql ，然后在1分鐘后 primary 如果還不能正常工作，則 192.168.198.22 將變為主庫，這個過程其實和MHA 沒有什么區別

1 在關閉 primary 前的和關閉后的圖

2 ?關閉primary 的圖

3? 切換成功，從庫已經可以進行寫操作

好了到目前為止，POSTGRESQL 的高可用，手動，自動 都是可以的，沒有任何問題。

問題是到底怎么做的，這就是依靠 repmgr 的另一個功能? repmgrd 組件來進行的監控，并在出現問題后通過配置進行切換的方法。

問題的repmgrd 是什么 (具體怎么做的先了解他是什么什么東西再說)

repmgrd是一個管理和監視守護進程，它在復制集群中的每個節點上運行。它可以自動執行一些操作，比如故障轉移和更新備用服務器，并提供關于每個備用服務器狀態的監視信息。

在使用repmgrd 的情況下，需要將其與postgresql進行綁定，也就是需要在

shared_preload_libraries = 'repmgr' ?中進行配置,需要加載到共享庫。(這不是高可用的內容，這是安裝POSTGRESQL 是的一些配置，如不清楚，請自行翻看以前的安裝文字或百度)

在使用repmgrd 進行主從切換的有幾個需要注意的地方 (其實和MHA 差不多)

1 在主從切換的過程中，等待多長時間來判斷主庫已經無法啟動了或不是因為網絡原因造成的問題，或及時是網絡造成的問題，多長時間能容忍，不切換。

2 切換的過程如果不成功怎么辦，什么可能的因素會導致切換失敗

3 多節點，如果切換，其他的節點是否可以連接到新的主上，并繼續工作

4 跨數據中心的怎么來進行高可用的規劃。

1? 在主從切換的過程中，等待的時間要和你的當前的運維基礎有關，如果你本身的網絡基礎就不好，還設置的比較短的診斷時間，那只能是給你自己平添煩惱

2? 切換失敗后的問題分析診斷，以及恢復

3? 多從節點的換主，后續安排工作的自動化

4? 跨數據中心的高可用，在網絡以及切換上的考量

這里基本上 repmgr 與 repmgrd 都有相關的安排和設置

1 ?主失敗后等待切換時間的設置在 repmgr.conf 文件中，紅色標注的地方

這里分別是在設置重新連接主庫的次數 和 時間間隔，?

reconnect_attempts ?*? reconnect_interval ?等于最終主庫無響應(包含網絡問題)后的切換前的重試時間，所以這里就是第一個問題，如果你的網絡不穩定，或者跨機房，你自己就的適當的調整參數，已適應你出現問題后的情況。

2 切換不成功的大概率可能性是從庫在從事其他的工作，而不是standby，所以這你就需要衡量一下，到底你的這個standby 的重要性是什么，是要協同工作，讀寫分離，還是就是一個standby 隨時待命來進行切換。當你有多個standby 的時候，你還可以調整你從庫的 priority ?(這點和 MYSQL的? MGR 中的 priority 有點像，其實也是一個意思，這里就不啰嗦了)

3 多節點，例如你有三個postgresql 的節點其中一主兩從，當其中主節點失效后其中一個變為主節點，但另一個從節點也需要繼續工作，需要鏈接到新的主上，這個工作在POSTGRESQL 怎么做，因為是物理復制，不是邏輯復制，所以也沒有那么簡單。

4 跨數據中心的postgresql 則需要考慮的問題是跨數據中心的網絡問題，以及腦裂問題，例如部署一定是單數節點，那單數節點的情況下，那邊的節點數量要多，而多的那邊放置的是什么節點，例如我就兩臺postgresql 主從，跨數據中心，但我怎么能防止腦裂，則就需要引入 wintness 服務器，也就是postgresql 見證服務器，他一般放置在數據中心的 主庫位置，本身不參與數據的復制和分發，(這點有點類似 SQL SERVER ?鏡像功能的見證服務器，雖然SQL SERVER 新的版本 鏡像功能被取消了)如果主變得不可用備用可以決定是否它能促進本身也不用擔心“分裂的場景，如果它不能看到證人或主服務器,很可能有一個網絡級中斷,它不應該促進本身。如果它可以看到見證而不是主節點，這證明不存在網絡中斷，主節點本身不可用。

這期就到這里，下期會開始進行實際的 postgresql? 自動故障切換處理的設置，以及相關文字

總結

以上是生活随笔為你收集整理的postgresql 集群_谁说postgresql 没有靠谱的高可用（2）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。