誰說 PostgreSQL 沒有靠譜的高可用（1）
- 2019 年 12 月 16 日
- 筆記
最近問postgresql 那個高可用靠譜的人越來越多，其實我也試過幾種postgresql 的高可用方案，而最近聽到的聲音是 PostgreSQL 沒有靠譜的高可用方案。所以就有了這篇文字
——————————————————————————————
今天說的是另一種PG的高可用方案，這種方案的好的地方
1 大廠支援
2 配置簡單靠譜，沒有眾多依賴包安裝後，還出問題讓你有想自殺的意願，或者是相關的技術文字少，解決問題困難的尿點。
這個高可用的方案已經在生產上使用了有一段時間，目前沒有出過問題，之前寫過，但是在這一段時間的使用中也發現了一些問題，所以準備詳細的對這個高可用方案來詳細的說說，也避免某些挑刺的說 PG 沒有靠譜的高可用這樣的笑話，繼續存在。
這個高可用的方式就是repmgr ，2象限公司的產品。（免費的），以下的文字中的PG的版本是 11.2 ，REPMGR 是 4.4 版本。由於功能比較多，所以一次也寫不完，只能分期的寫，今天的文字要做到的是 兩台 POSTGRESQL ，完成手動切換。
首先你需要安裝2台postgresql ，這裡假設你已經安裝完畢了（安裝當然是編譯安裝，如果不是編譯安裝則我不保證不會出其他的問題，之前有一篇是關於編譯安裝的，當然也可以去 「德哥」的github 上去找專業的文字關於POSTGRESQL 的安裝，水不淺）
1 安裝完畢的POSTGRESQL首先能有進行 replication 的條件
2 兩台postgresql 要配置一樣，包含配置文件，以及extension等等
這裡為了便於下面理解兩台機器的
192.168.198.21 主庫
192.168.198.22 備庫
其實我們配置一台機器就可以了，我們在一台機器（主機）
操作以下的命令
create database repmgr;
create user repmgr with password 'repmgr'; （密碼您隨意）
alter user repmgr superuser login;
alter database repmgr owner to repmgr;
對 repmgr 解包進行編譯
在確認已經編譯好repmgr 後，需要對兩台機器進行ssh 免密的工作
這裡的免密建議是基於你操控postgresql 的賬戶，而不是root
（註：免密的工作這裡如是MYSQL的DBA 這將不是很難理解的工作，因為MHA就是這麼乾的）
另外還需要配置repmgr 高可用使用的通訊賬戶，也需要進行免密的工作，需要在你操作postgresql的賬戶中目錄位置設置.pgpass ，內容請參見下圖
其實如果配置過mha ，對這樣的事情也是很容易理解）
另外也需要對 pg_hba.conf 進行配置，配置方法見下圖 （可能懂的會在這裡有疑問，但這裡的確是需要這樣設置，官網的文檔）
https://repmgr.org/docs/4.4/quickstart-authentication.html
在做完這一切後，我們需要配置 repmgr.conf 文件 （其實這還是和MHA 的配置方式類似，所以如果你是MYSQL DBA 則PG的高可用方式的學習成本會很低）
node_id=1 集群中的標識 注意這個一個集群不能有重複，一般用數字來
node_name='192.168.198.21' 需要給節點一個註冊的名字，這裡可以使用IP 也可以使用機器名等等
conninfo='host=192.168.198.21 dbname=repmgr user=repmgr connect_timeout=2'
本地連接資訊，repmgr 操作本地時的連接資訊
data_directory='/pgdata/data' 指定當前主機的數據目錄
replication_user='repmgr' 進行複製的操作的賬戶
replication_type='physical' 複製的方式
repmgr_bindir='/usr/local/postgres/bin' repmgr 的執行文件的目錄
pg_bindir='/usr/local/postgres' 配置PG的執行文件
另一台機器，需要在 node_id , node_name , conninfo 等位置做改變，
我們到目前小結一下當前的兩台機器的狀況
主機，已經註冊repmgr ，伺服器開啟的狀態，可以接受repmgr 的遠程連接免密的方式，備庫關機，備庫的數據目錄是清空的狀態（因為要開始進行主庫拉數據的操作）
下面我們就要使用一下的命令來進行 –dry-run (mysql的DBA 是不是很驚喜 和pt 工具一路貨)
repmgr -h 192.168.198.21 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone –dry-run
可以看到–dry-run 沒有問題直接執行命令進行 clone
repmgr -h 192.168.198.21 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
然後在clone 成功後，其實就是pg_basebackup ，在這以後需要修改standby 機器中的postgresql,conf 文件中的 listen 地址改為本機的地址
（這些工作其實也是做 primary standby 的工作，和高可用本身是沒有關係的，知識 repmgr 幫助你做了這件事）
啟動伺服器，正常，並開始複製
如果到這裡出了問題，可能的原因
1 pg_hba.conf 設置的有問題
2 postgresql.conf 從庫 沒有改 postgresql,conf 監聽地址
（請補充POSTGRESQL 基礎知識）
下一步我們就需要對複製進行一個驗證（如果有自信就跳過此步驟）
在從庫我們查看目前的複製是否OK ，下圖顯示OK
然後在從庫執行
repmgr -f /etc/repmgr.conf standby register
註冊成功後
目前大部分的高可用（手動切換）的工作已經完成了百分之80%
repmgr -f /etc/repmgr.conf cluster show
通過上面的圖和命令可以很順利查看，兩台機器的主從狀態。
寫到下面，可能有人要吐槽我了，人家都自動，你手動，你腦子進水了。
1 POSTGRESQL 的repmgr 主從切換，是可以自動的，但這期寫不完
2 如果使用mysql 比較順溜的，到這裡馬上就可以反映出一個問題，MHA 我切換我也沒有用 MHA 去偵測，我也是通過其他的方式來檢測，然後使用 MHA 命令切換方式來進行高可用的切換。
話說到這裡已經說的很明了，你要是有MYSQL的高可用MHA的解決方案，到這裡你自己已經有主意了，還有必要看下去的原因就是，怎麼手動切換。然後你就可以放飛自我了。
想說 POSTGRESQL 沒有靠譜高可用方式的，打臉不
下面就開始手動切換
repmgr -f /etc/repmgr.conf standby switchover -U repmgr –verbose
好了在切換命令開始後，主從開始切換，參見下圖
切換後，我們在主機上查看狀態
主機已經變成從庫，從庫已經升級為主庫
在從庫上查看，很清晰的告訴你，主庫已經是 22 ，從庫變成了21
這也是和MHA 不一樣的地方，如果你的失敗的主庫還有挽救的餘地，則還是可以讓他變成從庫，繼續服務的，當然也是有時間限制的，默認一分鐘的嘗試，否則就放棄了。
OK 今天就到這裡，下期的寫寫一些命令，和自動切換的方法
