Greenplum集群主要包括Master節點和Segment節點，Master節點稱之為主節點，Segment節點稱之為數據節點。Master節點與Segment節點都是有備份的，其中Master節點的備節點為Standby Master(不能夠自動故障轉移)，Segment是通過Primary Segment與Mirror Segment進行容錯的。通過本文你可以了解：
-
Greenplum數據庫的高可用(HA)原理 -
Greenplum生產集群中master節點故障恢復 -
greenplum生產集群中segment故障檢測與恢復 -
Segment節點故障恢復原理與實踐
Greenplum數據庫的HA
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服務器和備用master服務器同步后，standbymaster服務器將通過walsender 和 walreceiver 的復制進程保持最新狀態。該walreceiver是standby master上的進程， walsender流程是primary master上的流程。這兩個進程使用基於預讀日志（WAL）的流復制來保持primary master和standby master服務器同步。在WAL日志記錄中，所有修改都會在應用生效之前寫入日志，以確保任何進程內操作的數據完整性。
由於primary master不包含任何用戶數據，因此只需要在主master和備份master之間同步系統目錄表(catalog tables)。當這些表發生更新時，更改的結果會自動復制到備用master上，以確保與主master同步。
如果primary master發生故障，管理員需要使用gpactivatestandby工具激活standby master。可以為primary master和standby master配置一個虛擬IP地址，這樣，在primary master出現故障時，客戶端程序就不用切換到其他的網絡地址，因為在master出現故障時，虛擬IP地址可以交換到充當primary master的主機上。
mirror segment概述
當啟用Greenplum數據庫高可用性時，有兩種類型的segment：primary和mirror。每個主segment具有一個對應的mirror segment。主segment接收來自master的請求以更改主segment的數據庫，然后將這些更改復制到相應的mirror segment上。如果主segment不可用，則數據庫查詢將故障轉移到mirror segment上。
Mirror segment采用物理文件復制的方案---primary segment中數據文件I / O被復制到mirror segment上，因此mirror segment的文件與primary segment上的文件相同。Greenplum數據庫中的數據用元組(tuple)表示，元組被打包成塊（block）。數據庫的表存儲在由一個或多個塊組成的磁盤文件中。對元組進行更改操作，同時會更改保存的塊，然后將其寫入primary segment上的磁盤並通過網絡復制到mirror segment。Mirror segment只更新其文件副本中的相應塊。
對於堆表(heap)而言，塊被保存在內存緩存區中，直到為新更改的塊騰出空間時，才會將它們清除，這允許系統可以多次讀取或更新內存中的塊，而無需執行昂貴的磁盤I / O。當塊從緩存中清除時，它將被寫入磁盤並復制到mirror segment主機的磁盤。當塊保存在緩存中時，primary segment和mirror segment具有不同的塊鏡像，但是，數據庫仍然是一致的，因為事務日志已經被復制了。
AO表(Append-optimized)不使用內存緩存機制。對AO表的塊所做的更改會立即復制到mirror segment上。通常，文件寫入操作是異步的，但是打開、創建和同步文件是“同步復制”的，這意味着primary segment的塊需要從mirror segment上接收確認。
如果primary segment失敗，則文件復制進程將會停止，mirror segment會自動作為活動segment實例，活動mirror segment的系統狀態會變為“ 更改跟蹤”(Change Tracking)，這意味着在primary segment不可用時，mirror segment維護着一個系統表和記錄所有塊的更改日志。當故障的primary segment被修復好，並准備重新上線時，管理員啟動恢復過程，系統進入重新同步狀態。恢復過程將記錄的更改日志應用於已修復的primary segment上。恢復過程完成后，mirror segment的系統狀態將更改為“已同步 ”。
如果mirror segment在primary segment處於活動狀態時失敗或無法訪問，則primary segment的系統狀態將更改為“ 更改跟蹤”，並且它會記錄更改的狀態，用於mirror segment的恢復。
-
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配置。
-
Spread mirroring方式
Spread mirroring方式是指將每個主機的mirror segment分布在多個主機上，這樣，如果任何單個主機發生故障，該主機的mirror segment會分散到其他多個主機上運行，從而達到負載均衡的效果。僅當主機數量多於每個主機的segment數時，才可以使用Spread方式。下圖說明了Spread mirroring方式。
Master節點故障恢復
如果primary master節點失敗，日志復制進程就會停止。可以使用gpstate -f命令查看standby master的狀態，使用gpactivatestandby命令激活standby master。
激活Standby master
-
(1)確保原來的集群中配置了standby master
-
(2)在standby master主機上運行gpactivatestandby命令
$ gpactivatestandby -d /data/master/gpseg-1-d參數是指standby master的數據目錄，一旦激活成功，原來的standby master就成為了primary master。 -
(3)執行激活命令后，運行gpstate命令檢查狀態
$ gpstate -f新激活的master的狀態是active，如果已經為集群配置一個新的standby master節點，則其狀態會是passive。如果還沒有為集群配置一個新的standby master，則會看到下面的信息：No entries found，該信息表明尚未配置standby master。
-
(4)在成功切換到了standbymaster之后，運行ANALYZE命令，收集該數據庫的統計信息
$ psql postgres -c 'ANALYZE;' -
(5)可選：如果在成功激活standby master之后，尚未指定新的standby master，可以在active master上運行gpinitstandby命令，配置一個新的standby master
$ gpinitstandby -s new_standby_master_hostname
恢復到原來的設置(可選的)
-
(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
檢查standby master的狀態
可以通過查看視圖pg_stat_replication，來獲取更多的信息。該視圖可以列出walsender進程的信息，下面的命令是查看walsender進程的進程id和狀態信息。
$ psql postgres -c 'SELECT procpid, state FROM pg_stat_replication;'
segment節點故障檢測與恢復
概述
Greenplum數據庫服務器（Postgres）有一個子進程，該子進程為ftsprobe，主要作用是處理故障檢測。ftsprobe 監視Greenplum數據庫陣列，它以可以配置的間隔連接並掃描所有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。
檢測和管理失敗的segment
使用工具命令查看
啟用mirror備份后，當primary segment發生故障時，Greenplum會自動故障轉移到mirror segment。如果每個數據部分所在的segment實例都是在線的，則用戶可能無法意識到segment已經出現故障。如果在發生故障時正在進行事務，則正在進行的事務將回滾並在重新配置的segment集上自動重新啟動。
如果整個Greenplum數據庫系統由於segment故障而變得不可訪問（例如，如果未啟用mirror備份或沒有足夠的segment在線），則用戶在嘗試連接數據庫時將看到錯誤。返回到客戶端程序的錯誤可能表示失敗。例如：ERROR: All segment databases are unavailable
-
(1)在master節點上，運行gpstate命令，使用-e參數顯示錯誤的segment
$ gpstate -e標記為
Change Tracking的segment節點表明對應的mirror segment已經宕機。 -
(2)要獲取有關故障segment的詳細信息，可以查看 gp_segment_configuration目錄表
$ psql -c "SELECT * FROM gp_segment_configuration WHERE status='d';" -
(3) 對於失敗的segment實例，記下主機，端口，初始化時的角色和數據目錄。此信息將幫助確定要進行故障排除的主機和segment實例。
-
(4) 顯示mirror segment詳細信息，運行下面命名：
$ gpstate -m
檢查日志文件
日志文件可以提供信息以幫助確定錯誤的原因。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主機，則可以重啟該segment主機。
-
(3)如果該segment主機上線之后，可以通過master連接，則在master主機上運行下面命令，重新激活失敗的segment
$ gprecoverseg -
(4)恢復進程會顯示故障segment並標識需要同步的已更改文件。這個過程可能需要一些時間， 等待該過程完成。在此過程中，數據庫不允許寫入操作。
-
(5)在 gprecoverseg完成后，系統進入重新同步模式並開始復制已更改的文件。當系統處於聯機狀態並接受數據庫請求時，此進程在后台運行。
-
(6)重新同步過程完成后，系統狀態為“已同步”（ 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
從雙重故障中恢復
在雙重故障情況下，即primary segment和mirror segment都處於失敗狀態。如果不同segment的主機同時發生硬件故障，則會導致primary segment和mirror segment都處於失敗狀態，如果發生雙重故障，Greenplum數據庫將不可用。要從雙重故障中恢復，執行如下步驟：
-
(1)重啟greenplum數據庫
$ gpstop -r -
(2)再重啟系統之后，運行gprecoverseg命令
$ gprecoverseg -
(3)在gprecoverseg執行結束后，運行gpstate命令查看mirror狀態信息
$gpstate -m -
(4)如果segment仍是“Change Tracking”狀態，則運行下面命令：
$ gprecoverseg -F
從segment主機故障中恢復
如果主機處於不可操作狀態（例如，由於硬件故障），可以將segment恢復到備用主機上。如果啟用了mirror segment，則可以使用gprecoverseg命令將mirror segment恢復到備用主機。例如：
$ gprecoverseg -i recover_config_file
生成的recover_config_file文件的格式為：
filespaceOrder=[filespace1_name[:filespace2_name:...]failed_host_address:
port:fselocation [recovery_host_address:port:replication_port:fselocation
[:fselocation:...]]
例如，要在沒有配置其他文件空間的情況下恢復到與故障主機不同的另一台主機（除了默認的pg_system文件空間）：
filespaceOrder=sdw5-2:50002:/gpdata/gpseg2 sdw9-2:50002:53002:/gpdata/gpseg2
該gp_segment_configuration和pg_filespace_entry系統目錄表可以幫助確定當前的段配置，這樣可以計划mirror的恢復配置。例如，運行以下查詢：
=# SELECT dbid, content, hostname, address, port,
replication_port, fselocation as datadir
FROM gp_segment_configuration, pg_filespace_entry
WHERE dbid=fsedbid
ORDER BY dbid;
上述命令會輸出:
新恢復的segment主機必須預先安裝Greenplum數據庫軟件，並且其配置要與現有的segment主機一致。
Segment故障恢復原理與實踐
Greenplum集群環境介紹
該生產環境集群由四台服務器構成，其中一台為primary master節點，一台為standby master節點，兩外兩台為segment節點，每個segment節點有四個segment(兩個primary segment，兩個mirror segment)，segment采用group方式進行備份(sdw1的備份都在sdw2上，sdw2的備份都在sdw1上)，其角色分配如下圖所示：
segment故障檢查
-
gpstate -m日志信息
-
gpstate -c 日志信息
-
gpstate -e 日志信息
-
gpstate -s 日志信息
(1)sdw1節點的日志信息
(1)sdw2節點的日志信息
故障說明
Sdw1節點primary segment正常，mirror segment被激活，其mirror segment為sdw2節點上的primary segment備份。Sdw2節點primary segment失敗，mirror segment失敗。此時集群環境能夠正常提供服務，全部負載到sdw1節點上。
使用select * from gp_segment_configuration查看segment角色信息，如下圖所示：
segment故障恢復
-
在master主機上運行下面命令，重新激活失敗的segment
$ gprecoverseg
-
運行gpstate 命令用於驗證重新同步過程狀態
$ gpstate -m
當primary segment發生故障時，mirror segment會被激活為primary segment。運行gprecoverseg命令之后，失敗的primary segment成為了mirror segment，而被激活的mirror segment成為了primary segment，segment實例不會返回到在系統初始化時配置的首選角色。這意味着某些segment主機上可能運行多個primary segment實例，而某些segment主機上運行較少的segment，即系統可能處於潛在的不平衡狀態。如下圖所示，sdw1上的mirror segment變為了primary segment，sdw2上的primary segment變為了mirror segment。即sdw2的primary segment運行在sdw1節點上，系統處於不平衡狀態。
此時GPCC的狀態為：
-
運行gprecoverseg命令，使用-r參數將segment恢復到原來初始化時的角色設置
$ gprecoverseg -r查看gpcc狀態:
小結
本文主要介紹了GP的高可用原理及實踐。首先介紹了Master與Segment的容錯策略，然后介紹了Master節點與Segment節點故障恢復的步驟，最后給出了一個完整的實踐過程。
完
本文分享自微信公眾號 - 大數據技術與數倉（gh_95306769522d）。
如有侵權，請聯系 support@oschina.cn 刪除。
本文參與“OSC源創計划”，歡迎正在閱讀的你也加入，一起分享。