@
1. 問題描述
在項目中使用了Greenplum做分析型數據庫，Greenplum自身已經提供了高可用方案，Master節點提供Sdanby備用節點，Segment數據節點每個節點都有對應mirro節點。
但是Greenpplum提供的高可用方案，其實是存在缺陷的，就是master節點出現故障后，standby節點是不會自動啟動的，需要人工干預（segment數據節點會自動切換），這樣就會導致兩個問題：
（1）當Greenpplum的Master節點出現故障后，需要人工干預去激活並切換到Standby節點，一般公司是有運維團隊的，會通過進程監控並通知相關人員來處理，但是這個過程是需要一定時間的，假如用戶在使用，肯定會有所感知的，會影響實際業務。
（2） 最致命的是將主節點切換到Standby節點后，Greenpplum的訪問IP發生了變化，這時候連接Greenpplum的Web服務必須修改連接IP才能訪問，一般情況下是需要重啟應用服務器的，假如連接Greenpplum的是多個系統，並且是以集群的方式部署啟動的的，重啟的代價可能會很高。
2. 解決方案
2.1 Greenplum架構簡單介紹
2.1.1 Greenplum架構圖
數據庫連接通過Master節點進行訪問，跟oracle、mysql、postgre等關系型數據庫連接方式一樣
2.1.2 Greenplum提供的高可用方案
主節點Master節點有standby備用節點，數據節點segement存在mirrio（一般存儲在臨近服務器上）。
2.2 使用keepalived+greenplum實現真正的高可用
2.2.1 keepalived+greenplum架構圖
2.2.2 架構圖解析
（1） 在Greenplum的master節點和standby節點部署keepalive服務，使用keepalive監控greenplum的進程狀態和服務可用性；
（2） 采用keeplived的機制，在master和standby 上面生成一個虛擬IP，應用系統配置的連接地址為該虛擬IP地址，當master節點出現故障后，由Keepalived機制來保證切換到standby節點，需要特別注意的是切換到standby節點的時候，需要首先激活Standby節點，這樣就解決了greenplum主備節點的無縫切換
2.3 高可用方案存在的問題
該高可用方案是通過比較成熟的keepalived來保證主從節點的切換，彌補了Greenplum本身高可用架構的不足，基本能解決大部分問題，認為是可行的。
但是也存在不足之處，就是假如主節點上的keepalived出現了故障，但是Greenplum服務正常；這時候虛擬IP已經漂移到Standby對應IP節點，但是因為Greenplum的Master服務其實是正常，Standby服務會激活失敗，進而導致服務不可用，但是該情況幾率較小，后續可以考慮將keepalived進程增加到運維進程監控中。