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的恢復配置，例如，運行以下查詢：

標籤：大數據

上一篇：提高資料的安全性和可控性，數堆疊基于 Ranger 實作的 Spark SQL 權限控制實踐之路

下一篇：返回列表