Greenplum資料庫中segment故障檢測

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

   標記為Change Tracking的segment節點表明對應的mirror segment已經宕機。

(2)要獲取有關故障segment的詳細信息，可以查看 gp_segment_configuration目錄表。

(3) 對於失敗的segment實例，記下主機，埠，初始化時的角色和數據目錄。此信息將幫助確定要進行故障排除的主機和segment實例。

(4) 顯示mirror segment詳細信息，運行下麵命名：

1.2.2檢查日誌文件

日誌文件可以提供信息以幫助確定錯誤的原因。Master實例和segment實例都有自己的日誌文件，這些日誌文件位於pg_log的目錄下。Master的日誌文件包含最多信息，應該首先檢查它。

使用 gplogfilter工具檢查Greenplum資料庫日誌文件，可以獲取額外信息。要檢查segment日誌文件，可以在master主機上使用gpssh命令運行 gplogfilter。

       (1)使用 gplogfilter 檢查master日誌文件的WARNING, ERROR, FATAL 或者 PANIC日誌級別消息

       (2)使用 gpssh 檢查每個segment實例上的日誌級別為WARNING, ERROR, FATAL 或者 PANIC的消息。例如：

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主機

（2）如果是阻止master主機連接segment主機，則可以重啟該segment主機。

（3）如果該segment主機上線之後，可以通過master連接，則在master主機上運行下麵命令，重新**失敗的segment

（4）恢復進程會顯示故障segment並標識需要同步的已更改文件。這個過程可能需要一些時間， 等待該過程完成。在此過程中，資料庫不允許寫入操作。

（5）在 gprecoverseg完成後，系統進入重新同步模式並開始複製已更改的文件。當系統處於聯機狀態並接受資料庫請求時，此進程在後臺運行。

（6）重新同步過程完成後，系統狀態為“已同步”（ Synchronized）。運行gpstate 命令用於驗證重新同步過程狀態

2.2將所有的segment恢復到原來的角色設置

當primary segment發生故障時，mirror segment會被**為primary segment。運行gprecoverseg命令之後，當前活動的segment是primary segment，失敗的primary segment成為了mirror segment。segment實例不會返回到在系統初始化時配置的首選角色。這意味著某些segment主機上可能運行多個primary segment實例，而某些segment主機上運行較少的segment，即系統可能處於潛在的不平衡狀態。要檢查不平衡的segment並重新平衡系統，可以使用如下命令：

所有segment必須線上並完全同步以重新平衡系統，資料庫會話在重新平衡期間保持連接，但正在進行的查詢將被取消並回滾。

(1)運行下麵命令，查看mirror segment的角色和同步狀態

(2)如果有mirror segment處於非同步狀態，等待他們同步完成

(3)運行gprecoverseg命令，使用-r參數將segment恢復到原來初始化時的角色設置

(4)運行gpstate -e命令，確認所有的segment是否恢復到初始化時的角色設置

2.3從雙重故障中恢復

在雙重故障情況下，即primary segment和mirror segment都處於失敗狀態。如果不同segment的主機同時發生硬體故障，則會導致primary segment和mirror segment都處於失敗狀態，如果發生雙重故障，Greenplum資料庫將不可用。要從雙重故障中恢復，執行如下步驟：

(1)重啟greenplum資料庫

(2)再重啟系統之後，運行gprecoverseg命令

(3)在gprecoverseg執行結束後，運行gpstate命令查看mirror狀態信息

(4)如果segment仍是“Change Tracking”狀態，則運行下麵命令：

2.4從segment主機故障中恢復

如果主機處於不可操作狀態（例如，由於硬體故障），可以將segment恢復到備用主機上。如果啟用了mirror segment，則可以使用gprecoverseg命令將mirror segment恢復到備用主機。例如：

生成的recover_config_file文件的格式為：

   例如，要在沒有配置其他文件空間的情況下恢復到與故障主機不同的另一臺主機（除了預設的pg_system文件空間）：

該gp_segment_configuration和pg_filespace_entry系統目錄表可以幫助確定當前的段配置，這樣可以計劃mirror的恢復配置。例如，運行以下查詢：