353
人物
Deepgreen & Greenplum 高可用（二） - Master故障轉移
上一篇文章中提到了Segment節點的故障轉移，其中主要涉及Mirror添加、故障自動切換、故障修複後balanced到原集群狀態，以及一些建議。具體請移步傳送門-->《Deepgreen & Greenplum 高可用（一） - Segment節點故障轉移 》。
書接上文，今天來談一談Master節點的故障轉移。
一、首先從理論上來講，要達到Master節點的單點保障，Master Standby要與Master部署在不同的服務器上。當Master節點故障時，同步程序停止，此時手動在Master主機激活Standby。激活Standby時，同步日誌被用來恢複Master最後一次事務成功提交時的狀態。另外，在激活Standby主機同時，可以指定一個新的Standby。
下麵我們開始實驗：
1.首先給原有集群添加Standby
gpinitstandby -s reverse <<--Standby所在主機名，與/etc/hosts中相對應2.通過SQL查看現有Master及Standby Master狀態
postgres=# select string_agg(role||'-'||hostname,'|') from gp_segment_configuration where content='-1';
string_agg
--------------
p-flash|m-reverse3.模擬Master故障並切換到Standby
# 查詢Master進程
ps -ef | grep postgres
kill -9 3897 <<-- 上麵查詢到的Master進程pid# 測試是否可以連接到集群（失敗）
psql -d postgres#切換到Standby
gpactivatestandby -d ${MASTER_DATA_DIRECTORY}# 測試是否可以連接到集群（成功）
psql -d postgres#如果想在切換的同時創建一個新的Standby，可以執行如下命令
gpactivatestandby -d ${MASTER_DATA_DIRECTORY} -c new_standby_hostname4.切換完成後，在新Master主機上連接數據庫並運行ANALYZE
psql dbname -c 'ANALYZE;'至此，切換完成。
二、與Mirror一樣，因為Standby一般不會單獨占用一台機器，通常部署在某個Segment節點之上，所以長期使用Standby接管服務，會導致Standby主機爭搶Segment實例資源。通常在原Master修複後，應盡快切換為原集群狀態，下麵我們來做這個實驗。
1.首先在原Standby主機（現已經承擔Master服務）上，執行如下命令，將Standby初始化到原Master主機（剛修複的問題機器）
gpinitstandby -s flash2.在當前承擔Master服務的Standby主機上停止Master服務
gpstop -m3.在原Master主機上重新激活Master服務
gpactivatestandby -d $MASTER_DATA_DIRECTORY4.激活之後，通過下麵命令查看狀態
gpstate -f5.一旦狀態正常，便可將原Standby主機重新初始化
gpinitstandby -s reverse至此，集群已經恢複到原始狀態，這裏麵關於原Master、現Master、原Standby和現Standby的概念，有點繞，需要認真品味。
三、最後分享另外兩個與Standby相關的操作
1. 同步Standby並更新到最新的同步
gpinitstandby -s standby_master_hostname -n2.刪除Standby
gpinitstandby -s standby_master_hostname -r備注：
- Standby可以輕鬆添加和刪除，然而Mirror卻隻允許添加，不允許刪除。
- 需要注意，Master的熱備Standby需要手工激活，並且使用不同的訪問IP；而Segment的鏡像卻可以自動切換。
End~~
最後更新：2017-06-29 21:34:10