这是学习笔记的第 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的状态，如果出现异常就开始转储问题进行恢复，以下是巡检和恢复的部分日志。
完整的脚本内容如下：
代码语言：javascript复制#!/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小结：这个简单的脚本算是拯救了自己的碎片时间，也通过这样的故障自愈让自己解放一下。
