Greenplum Segment 的檢測機制
Greenplum叢集具有較好的容錯性和高可用性，其中一點就體現在segment映象機制上。接下來本文會簡單地闡述segment的作用以及segment映象機制是如何保證GP高可用的。
Segment簡介
-
Greenplum叢集由一個Master和多個segment組成
-
segment用來儲存資料
-
一臺機器可以有多個segment
-
每個segment是一個postgres資料庫例項
當Greenplum啟用映象時，對每個segment都有一對primary segment和mirror segment。 primary segment和mirror segment被分佈在不同的機器上，但是儲存的是同一份資料。
Segment故障切換
當Greenplum叢集啟用映象後，如果primary segment不可用，系統會啟用備用mirror segment。所以當一個或多個segment出現問題時，只要剩餘segment的所有資料可用，Greenplum叢集就可以保持正常執行。如果GP叢集沒有啟用映象，當一個segment發生故障後後導致整個GP叢集停止服務，直到所有segment恢復正常。
如果Master節點無法連線到一個segment，Master會在GP系統目錄中標記該segment狀態為宕機，並且啟用映象資料。
Segment故障檢測
在Master主機上，Postgres的主程序postmaster會派生一個子程序ftsprobe(FTS)用於故障探測。如果FTS失敗，postmaster會重啟它。FTS會按照資料庫配置週期性的請求各segment，並掃描segment的狀態。
如果FTS無法連線到某個segment，它會在資料庫系統目錄標記該segment的狀態為"down"。該segment在這期間無法被操作，直到進行恢復處理。
FTS配置引數：
-
gp_fts_probe_threadcount
- 探測Segment的執行緒數。預設值：16
-
gp_fts_probe_retries
- 嘗試探測一個Segment的次數。例如如果該設定是 5，在第一次嘗試失 敗後將會有4次重試。預設值：5
-
gp_fts_probe_timeout
- 在Master和Segment之間的探測超時時長，以秒計。預設值：20，最大 值：3600。
-
gp_fts_probe_interval
- 多長時間開始一次新的FTS迴圈，以秒計。例如如果設定是60並且探測 迴圈本身需要10秒，FTS處理會睡眠50秒。如果該設定是60並且探測循 環需要75秒，FTS程序睡眠0秒。預設值：60，最大值：3600。
-
gp_log_fts
- FTS的日誌級別。off、terse、verbose、debug。verbose可以被用在生產環境中為排查問題提供有用的資料。debug設定不應該被用在生產中。預設值：terse。
-
gp_segment_connect_timeout
- 允許一個映象做出響應的最大時間（以秒計）。預設值：180
FTS會通過向segment資料庫建立一個TCP連線來探測每一個primary segment資料庫，連線時使用註冊在gp_segment_configuration表中的主機名和埠。
註冊在gp_segment_configuration表中的主機名和埠如下圖：
如果連線成功，segment會執行一些簡單的檢查並返回結果給FTS。這些檢查包括對關鍵的segment目錄上執行一次stat以及檢查segment的內部故障。如果沒有檢測到問題，會給FTS一個正常反饋。
原始碼中的反饋結果包含如下：
如果FTS無法建立連線或者在超時後沒有收到一個回覆，則會重試。如果失敗的探測次數超過配置的最大次數，FTS會探測該segment的映象是否正常，然後更新gp_segment_configuration表標記primary segment為down，並且設定該映象作為primary segment執行。FTS會在gp_configuration_history中記錄該操作。
當只有一個活動的primary segment並且相應的映象宕機時，該primary segment會進入到"Change Tracking Mode"。在這種模式中，對該Segment的操作會被記錄，這樣可以同步映象而無需把primary segment的完整資料複製給mirror segment。
gprecoverseg命令可以恢復宕機的映象。
-
預設情況下，gprecoverseg執行一次增量恢復，把該映象置於resync模式中，然後開始把primary segment記錄的更改在映象上進行重放。
-
如果不能完成增量恢復，可以重新以-F選項執行gprecoverseg來執行完全恢復。這種操作會導致primary segment把所有的資料都複製給映象。
在gp_segment_configuration表中，每個Segment可以有三種模式：
-
change tracking
-
resync
-
synced
同時還可以有"up"或"down"兩種狀態。
gpcc的監控狀態如下圖：
gp_segment_configuration表還有兩個列role和preferred_role。
-
role：表示該segment資料庫的當前角色
-
preferred_role：表示該segment的原始角色。
在叢集正常時，所有segment的role和preferred_role都是匹配的。當它們不匹配時，每臺硬體主機上活動的primary segment數量發生傾斜。為了重新平衡該叢集並且讓所有的segment回到它們的首選角色，可以用-r選項執行gprecoverseg命令。
最後提醒各位Greenplum的使用者，雖然Greenplum有完善的容錯機制。但是當GP發生故障，主備segment切換後，會造成負載不均衡，耗費更多的系統資源，同時會大幅度降低查詢等操作的效率。所以，及時恢復失敗的segment，把所有segment恢復成原有的角色是非常必要的工作。