1.Greenplum數據庫中segment故障檢測
1.1概述
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。
1.2檢測和管理失敗的segment
1.2.1使用工具命令查看
啓用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 |
1.2.2檢查日誌文件
日誌文件可以提供信息以幫助確定錯誤的原因。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 |
2.恢復失敗的segment
如果master服務器無法連接到segment實例，則會在Greenplum數據庫系統目錄中將該segment標記爲“down”狀態。在管理員採取措施使segment實例重新上線之前，segment實例將保持脫機離線狀態。segment實例可能由於多種原因而不可用：
(1)segment主機不可用; 例如，由於網絡或硬件故障。
(2)segment實例未運行; 例如，沒Postgres的數據庫監聽進程。
(3)segment實例的數據目錄損壞或丟失; 例如，無法訪問數據，文件系統已損壞或磁盤發生故障。
2.1在啓用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 |
2.2將所有的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 |
2.3從雙重故障中恢復
在雙重故障情況下，即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 |
2.4從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主機一致。