Greenplum集羣主要包括Master節點和Segment節點，Master節點稱之爲主節點，Segment節點稱之爲數據節點。Master節點與Segment節點都是可以有備份的，其中Master節點的備節點爲Standby Master(不能夠自動故障轉移)，Segment是通過Primary Segment與Mirror Segment進行容錯的。通過本文你可以瞭解：
- Greenplum數據庫的高可用(HA)原理
- Greenplum生產集羣中master節點故障恢復
- Greenplum生產集羣中segment故障檢測與恢復
- Segment節點故障恢復原理與實踐
Greenplum數據庫的高可用原理
1. master mirroring概述
可以在單獨的主機或同一主機上部署master實例的備份或鏡像。如果primary master服務器宕機，則standby master服務器將用作熱備用服務器。在primary master服務器在線時，可以從primary master服務器創建備用master服務器。
Primary master服務器持續爲用戶提供服務，同時獲取Primary master實例的事務快照。在standby master服務器上部署事務快照時，還會記錄對primary master服務器的更改。在standby master服務器上部署快照後，更新也會被部署，用於使standby master服務器與primary master服務器同步。
Primary master服務器和standby master服務器同步後，standbymaster服務器將通過walsender 和 walreceiver 的複製進程保持最新狀態。該walreceiver是standby master上的進程， walsender流程是primary master上的進程。這兩個進程使用基於預讀日誌（WAL）的流複製來保持primary master和standby master服務器同步。在WAL日誌記錄中，所有修改都會在應用生效之前寫入日誌，以確保任何進程內操作的數據完整性。
由於primary master不包含任何用戶數據，因此只需要在主master和standby master之間同步系統目錄表(catalog tables)。當這些表發生更新時，更改的結果會自動複製到備用master上，以確保與主master同步。
如果primary master發生故障，管理員需要使用gpactivatestandby工具激活standby master。可以爲primary master和standby master配置一個虛擬IP地址，這樣，在primary master出現故障時，客戶端程序就不用切換到其他的網絡地址，因爲在master出現故障時，虛擬IP地址可以交換到充當primary master的主機上。
2. mirror segment概述
當啓用Greenplum數據庫高可用性時，有兩種類型的segment：primary和mirror。每個主segment具有一個對應的mirror segment。主segment接收來自master的請求以更改主segment的數據庫，然後將這些更改複製到相應的mirror segment上。如果主segment不可用，則數據庫查詢將故障轉移到mirror segment上。
Primary segment和Mirror segment之間的同步與primary master和standby master相同，也是採用基於WAL流的同步。
3. group mirroring方式
只要primary segment實例和mirror segment實例位於不同的主機上，mirror segment就可以以不同的配置方式放置在羣集中的主機上。每個主機必須具有相同數量的mirror segment和primary segment。默認mirror segment配置方式是group mirroring，其中每個主機的primary segment的mirror segment位於另一個主機上。如果單個主機發生故障，則部署該主機的mirror segment主機上的活動primary segment數量會翻倍，從而會加大該主機的負載。下圖說明了group mirroring配置。
4. Spread mirroring方式
Spread mirroring方式是指將每個主機的mirror segment分佈在多個主機上，這樣，如果任何單個主機發生故障，該主機的mirror segment會分散到其他多個主機上運行，從而達到負載均衡的效果。僅當主機數量多於每個主機的segment數時，纔可以使用Spread方式。下圖說明了Spread mirroring方式。
Master節點故障恢復
如果primary master節點失敗，日誌複製進程就會停止。可以使用gpstate -f命令查看standby master的狀態，使用gpactivatestandby命令激活standby master。
1. 激活Standby master
(1)確保原來的集羣中配置了standby master
(2)確保primary master已經停止運行，如果primary master仍在運行，提升standby master後，系統可能會有2個primary master，造成數據不一致
(3)在standby master主機上運行gpactivatestandby命令
$ gpactivatestandby -d /data/master/gpseg-1-d參數是指standby master的數據目錄，一旦激活成功，原來的standby master就成爲了primary master。
(4)執行激活命令後，運行gpstate命令檢查狀態
$ gpstate -f新激活的master的狀態是active，如果已經爲集羣配置一個新的standby master節點，則其狀態會是passive。如果還沒有爲集羣配置一個新的standby master，則會看到下面的信息：No entries found，該信息表明尚未配置standby master。
(5)在成功切換到了standbymaster之後，運行ANALYZE命令，收集該數據庫的統計信息
$ psql postgres -c 'ANALYZE;'(6)可選：如果在成功激活standby master之後，尚未指定新的standby master，可以在active master上運行gpinitstandby命令，配置一個新的standby master
$ gpinitstandby -s new_standby_master_hostname -P <port> -S <standby_master_datadir>2. 恢復到原來的設置(可選的)
(1)確保之前的master節點能夠正常使用
(2)在原來的master主機上，移除(備份)原來的數據目錄gpseg-1,比如：
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1(3)在原來的master節點上，初始化standby master，在active master上運行如下命令
$ gpinitstandby -s mdw(4)初始化完成之後，檢查standby master的狀態
$ gpstate -f顯示的狀態應該是–Sync state: sync
(5)在active master節點上運行下面的命令，用於停止master
$ gpstop -m(6)在原來的master節點(mdw)上運行gpactivatestandby命令
$ gpactivatestandby -d /data/master/gpseg-1(7)在上述命名運行結束之後，再運行gpstate命令查看狀態
$ gpstate -f確認原始的primary master狀態是active。
(8)在原來的standby master節點(smdw)上，移除(備份)數據目錄gpseg-1
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1(9)原來的master節點正常運行之後，在該節點上執行如下命令，用於激活standby master
$ gpinitstandby -s smdw -P <port> -S <standby_master_datadir>3. 檢查standby master的狀態
可以通過查看視圖pg_stat_replication，來獲取更多的同步信息。該視圖可以列出walsender進程的信息，下面的命令是查看walsender進程的進程id和狀態信息。
$ psql postgres -c 'SELECT pid, state FROM pg_stat_replication;'Segment節點故障檢測與恢復
1. 概述
Greenplum數據庫主節點服務器上，postmas進程有一個子進程ftsprobe，它的主要作用是處理segment節點的故障檢測和提升。ftsprobe 監視Greenplum數據庫segments節點，它週期性地掃描所有segment節點。如果 ftsprobe無法連接到segment，它會在Greenplum數據庫系統目錄中將segment標記爲”down”。在管理員啓動恢復進程之前，該segment是不可以被操作的。
啓用mirror備份後，如果primary segment不可用，Greenplum數據庫會自動故障轉移到mirror segment。如果segment實例或主機發生故障，系統仍可以運行，前提是所有在剩餘的活動segment上數據都可用。
要恢復失敗的segment，管理員需要執行 gprecoverseg 恢復工具。此工具可以找到失敗的segment，驗證它們是否有效，並將事務狀態與當前活動的segment進行比較，以確定在segment脫機時所做的更改。gprecoverseg將更改的數據庫文件與活動segment同步，並使該segment重新上線。管理員需要在在Greenplum數據庫啓動並運行時執行恢復操作。
禁用mirror備份時，如果segment實例失敗，系統將變得幾乎不可用。管理員需要手動恢復所有失敗的segment。
2. 檢測和管理失敗的segment
使用工具命令查看
啓用mirror備份後，當primary segment發生故障時，Greenplum會自動故障轉移到mirror segment。如果每個數據部分所在的segment實例都是在線的，則用戶可能無法意識到segment已經出現故障。如果在發生故障時正在進行事務（還未進入兩階段提交的第二階段），則正在進行的事務將被回滾。
如果整個Greenplum數據庫系統由於segment故障而變得不可訪問（例如，如果未啓用mirror備份或沒有足夠的segment在線），則用戶在嘗試連接數據庫時將看到錯誤。返回到客戶端程序的錯誤可能表示失敗。例如：
ERROR: failed to acquire resources on one or more segments在master節點上，運行gpstate命令，使用-e參數顯示錯誤的segment
$ gpstate -e
值得注意的是，即便是一組primary和mirror都發生了故障（double failure），在gp_segment_configuration中也只會有一個的status顯示爲’d’。這是因爲mirror發生故障時，ftsprobe不會再向primary進行探測了，進而不會將剩下的節點標記爲’d’。在進行query派發的時候，由於創建interconnect失敗，QD進程向用戶返回錯誤。
檢查日誌文件
日誌文件可以提供信息以幫助確定錯誤的原因。Master實例和segment實例都有自己的日誌文件，這些日誌文件位於pg_log的目錄下。Master的日誌文件包含最多信息，應該首先檢查它。
使用 gplogfilter工具檢查Greenplum數據庫日誌文件，可以獲取額外信息。要檢查segment日誌文件，可以在master主機上使用gpssh命令運行 gplogfilter。
(1)使用 gplogfilter 檢查master日誌文件的WARNING, ERROR, FATAL 或者 PANIC日誌級別消息
$ gplogfilter -t(2)使用 gpssh 檢查每個segment實例上的日誌級別爲WARNING, ERROR, FATAL 或者 PANIC的消息。例如：
$ gpssh -f seg_hosts_file -e 'source/usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t/data1/primary/*/pg_log/gpdb*.log' > seglog.out
恢復失敗的segment
如果master服務器無法連接到segment實例，則會在Greenplum數據庫系統目錄中將該segment標記爲“down”狀態。在管理員採取措施使segment實例重新上線之前，segment實例將保持脫機離線狀態。segment實例可能由於多種原因而不可用：
(1)segment主機不可用; 例如，由於網絡或硬件故障。
(2)segment實例未運行; 例如，沒Postgres的數據庫監聽進程。
(3)segment實例的數據目錄損壞或丟失; 例如，無法訪問數據，文件系統已損壞或磁盤發生故障。
在啓用mirror segment的情況下進行恢復
(1)確保master主機能夠ping通失敗的segment主機
$ ping failed_seg_host_address(2)在master主機上運行下面命令，重新激活失敗的segment
$ gprecoverseggprecoverseg的執行過程可能需要一些時間，在此過程中，數據庫不允許寫入操作。成功執行後，節點會作爲備節點來使用。
(3)恢復進程會顯示故障segment並標識需要同步的已更改文件。這個過程可能需要一些時間，等待該過程完成。在此過程中，數據庫不允許寫入操作。
(4)在 gprecoverseg完成後，系統進入重新同步模式並開始複製已更改的文件。當系統處於聯機狀態並接受數據庫請求時，此進程在後臺運行。
(5)重新同步過程完成後，系統狀態爲“已同步”（ Synchronized）。運行gpstate 命令用於驗證重新同步過程狀態
$ gpstate -m將所有的segment恢復到原來的角色設置
當primary segment發生故障時，mirror segment會被激活爲primary segment。運行gprecoverseg命令之後，當前活動的segment是primary segment，失敗的primary segment成爲了mirror segment。segment實例不會返回到在系統初始化時配置的首選角色。這意味着某些segment主機上可能運行多個primary segment實例，而某些segment主機上運行較少的segment，即系統可能處於潛在的不平衡狀態。要檢查不平衡的segment，可以使用如下命令：
$ gpstate -e所有segment必須在線並完全同步以重新平衡系統，數據庫會話在重新平衡期間保持連接，但正在進行的查詢將被取消並回滾。
(1)運行下面命令，查看mirror segment的角色和同步狀態
$ gpstate -m(2)如果有mirror segment處於非同步狀態，等待他們同步完成
(3)運行gprecoverseg命令，使用-r參數將segment恢復到原來初始化時的角色設置
$ gprecoverseg -r(4)運行gpstate -e命令，確認所有的segment是否恢復到初始化時的角色設置
$ gpstate -e雙重故障(double-fault)
在雙重故障情況下，即primary segment和mirror segment都處於失敗狀態。如果不同segment的主機同時發生硬件故障，則會導致primary segment和mirror segment都處於失敗狀態。如果發生雙重故障，Greenplum數據庫將不可用。
Segment故障恢復原理與實踐
1. Greenplum集羣環境介紹
該生產環境集羣由四臺服務器構成，其中一臺爲primary master節點，一臺爲standby master節點，兩外兩臺爲segment節點，每個segment節點有四個segment(兩個primary segment，兩個mirror segment)，segment採用group方式進行備份(sdw1的備份都在sdw2上，sdw2的備份都在sdw1上)，其角色分配如下圖所示：
2. segment故障檢查
gpstate -m日誌信息
gpstate -e 日誌信息
gpstate -e 日誌信息
gpstate -s 日誌信息
(1)sdw1節點的日誌信息
(2)sdw2節點的日誌信息
3. 故障說明
sdw1節點primary segment正常，mirror segment被激活，其mirror segment爲sdw2節點上的primary segment備份。sdw2節點primary segment失敗，mirror segment失敗。此時集羣環境能夠正常提供服務，全部負載到sdw1節點上。
使用select * from gp_segment_configuration查看segment角色信息，如下圖所示：
4. segment故障恢復
在master主機上運行下面命令，重新激活失敗的segment
$ gprecoverseg
運行gpstate 命令用於驗證重新同步過程狀態
$ gpstate -m
當primary segment發生故障時，mirror segment會被激活爲primary segment。運行gprecoverseg命令之後，失敗的primary segment成爲了mirror segment，而mirror segment被fts probe進程提升成爲primary segment。segment實例不會返回到在系統初始化時配置的首選角色。這意味着某些segment主機上可能運行多個primary segment實例，而某些segment主機上運行較少的segment，即系統可能處於潛在的不平衡狀態。如下圖所示，sdw1上的mirror segment變爲了primary segment，sdw2上的primary segment變爲了mirror segment。即sdw2的primary segment運行在sdw1節點上，系統處於不平衡狀態。
運行gprecoverseg命令，使用-r參數將segment恢復到原來初始化時的角色設置
$ gprecoverseg -r再次查詢gp_segment_configuration會發現，所有的 segment都處於up狀態，並且它們此時的角色和初始化集羣時分配的角色一致。
小結
本文主要介紹了GP的高可用原理及實踐。首先介紹了Master與Segment的容錯策略，然後介紹了Master節點與Segment節點故障恢復的步驟，最後給出了一個完整的實踐過程。