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

小结：这个简单的脚本算是拯救了自己的碎片时间，也通过这样的故障自愈让自己解放一下。