Greenplum的segment故障自愈小試

• 2019 年 11 月 11 日
• 筆記

這是學習筆記的第 2142 篇文章

在工作中，總是不可避免會碰到故障，最近Greenplum集群總是會時不時的拋出segment節點的問題，不過GP的高可用機制是比較完善的，數據segment節點出現故障，節點會從Primary切換到Mirror，相對還是很健壯的，另外Greenplum裡面的角色是我見過資料庫裡面的設計最全的，Master,Standby,Primary,Mirror全都齊了。

在一段時間的觀察和實踐之後，發現問題的情況都大抵相同，基本都是開發人員提交的重量級SQL導致，修復的步驟相對是比較常規的。

有的時候碰到節點問題的時候，還是很讓人糾結的，尤其是工作外的時間處理，其實是很佔用個人時間的，處理的步驟也是常規的，生成轉儲文件得到segment列表，然後恢復mirror節點，如果是角色發生了切換，還需要重新對調下角色。

我碰到的90%的場景下都是Primary和mirror的異常通訊，所以處理起來基本都是靠神器gprecoverseg ，執行-o和-i選項即可。

幾次三番幾次三番的處理之後，都有些麻木了，所以我就在想這樣的處理方式就不要麻煩我了，因為默認的處理方式是需要命令確認是否修復，在查看了gprecoverseg 的幫助之後，發現了額外的選項-a，可以自動確認。

所以就開始寫腳本，寫腳本的過程中剛好節點出現問題，就順手拿來做了下故障自愈測試。以下是我設置的crontab任務，每隔一個周期就會檢測segment的狀態，如果出現異常就開始轉儲問題進行恢復，以下是巡檢和恢復的部分日誌。

完整的腳本內容如下：

#!/bin/sh  . /home/gpadmin/.bash_profile  GP_Cmd="/usr/local/greenplum-db/bin/psql"    function check_segment_cnt(){  err_segment_cnt=`${GP_Cmd} -t -c "select count(*) from gp_segment_configuration where status='d';"`  echo $err_segment_cnt  }    err_segment_cnt=`check_segment_cnt`      if [ $err_segment_cnt -gt 0 ];then    echo '#### INFO: '`date` '## There are ' $err_segment_cnt 'segments have failed to connect ...' >> /tmp/gp_recovery.log  else    echo '#### INFO: '`date` '## There are ' $err_segment_cnt 'segments have failed to connect ...' >> /tmp/gp_recovery.log    exit  fi    /usr/local/greenplum-db/bin/gprecoverseg -o /home/gpadmin/recov >>/tmp/gp_recovery.log 2>&1    sleep 50;      if [ -s /home/gpadmin/recov ];then     echo '#### INFO: '`date` '##  segment recovery file is not empty,start segment recovery  ...' >>/tmp/gp_recovery.log    /usr/local/greenplum-db/bin/gprecoverseg -i /home/gpadmin/recov -a  >>/tmp/gp_recovery.log  2>&1  else    echo '#### INFO: '`date` '##  segment recovery file is empty  ...' >> /tmp/gp_recovery.log  fi    sleep 120;    err_segment_cnt=`check_segment_cnt`  echo '#### INFO: '`date` '## There are ' $err_segment_cnt 'segments have failed to connect ...' >> /tmp/gp_recovery.log  echo  >/home/gpadmin/recov

小結：這個簡單的腳本算是拯救了自己的碎片時間，也通過這樣的故障自愈讓自己解放一下。