greenplum集群实例频繁宕机

环境描述:

问题描述：

在生产环境中我们所维护的greenplum集群偶尔会遇到segments节点实例宕停的情况，导致实例宕停的因素比较多。如：硬件上的磁盘故障导致io较高，内网的网络波动。sql语法的不规范导致资源消耗过大，大批量的调度语句集中在一个时间点导致集群压力太大。相关参数上的设置过小等等。。。。。。这样的原因都会导致集群某一个或多个mirrror实例在固定的时间点宕机，以上的情况一般不会导致primary宕机，但是也不一定遇到primary也可以按照以下方法排查原因。

排查方法：

       一：排查是否是硬件的问题，查看主机日志messages。

        路径：/var/log/messages

        查看是否是降级导致的，磁盘降级的关键词根据主机厂商不同一般不一样。

              如果是内存或者别的硬件导致的就执行以下命令（如果是硬件导致可能会有primary实例宕停）

cat /var/log/messages | grep ker

具体的报错信息需根据经验判断

二：查看数据库日志

       需要查看的是宕停实例的数据库日志，并且需要快速获取路径。

       查看数据库状态

gpstate -e

这样看到的只是宕机的实例主机名无法获取到详细的路径，执行以下命令。

       可以看到主机名后面的就是宕停实例的目录路径

登录gp2切换到pg_log目录下

可以看到按日期生成的.csv文件，这就是数据库日志。但是有的文件后缀不是000000，是为什么？数据库日志文件本身就是“gpdb-年-月-日_时间“，显示000000是因为在凌晨12点整生成的，而那些不是000000的则是因为该实例宕停不在记录日志信息只有把实例拉起时才会继续记录，而拉起宕停实例的时间就会自动生成一个对应的.csv文件。

查看相应的日志文件可以看到红色标记的哪一行有“WARING“关键词，而后面的信息就是当该实例宕停时所打印的信息。而报错信息的大概意思就是”在连接时收到了关闭信息并且成功了“，为什么会导致这样的情况？

根据网上得到的方案可以修改的参数有这两个

这个参数简单的说就是在Master和Segment之间的探测超时时长。导致的原因可能时那个时间点集群的压力过大，通信超时，可以将时间调高点。

这里引用greenplum6.0.1的解释

等待Mirror响应的最长时间，缺省为600，单位是秒。 在FTS检测之外，gp_segment_connect_timeout参数限制的是Primary等待 Mirror响应的时间，在Primary向Mirror发送数据时，超过该参数设置的时间仍无法成功，Primary将会报告Master修改Mirror的状态为down，然后Primary将会持 续记录WAL日志，对于6之前的版本，Primary将进入change tracking状态。不过， 对于该参数，至少在6之前的版本，真正的超时时间是设定值的75%。

       三：sql语句的原因

              这里就需要在master主机部署一个记录集群会话的脚本，将宕机时间点的sql反馈给应用让他们检查是否有问题，或者将宕机时间点的会话分散执行。