Greenplum集群问题修复小结

最近GP集群频繁出现了一些抖动问题，抖动造成的结果就是GP集群的segment节点中primary或者mirror会出现切换。

问题在一周的时间里出现了两次，第一次是没有明确的结果和结论，第二次的时候，是发生了部分节点的问题。

从最开始看到这个问题的时候，我的内心是崩溃的，一个很自然的想法是可能网络出现了问题。

但是经过网络层的排查，没有发现相关的信息，所以网络层出现问题的概率较低。

然后排查系统层，系统层使用了多网卡的绑定，其实问题发生时网卡的荷载是很低的，所以这个问题从系统层引发的概率也较低。

当然上面的步骤很可能是并行检查的，完全没必要按部就班的串行来做。

GP集群的一个基本的架构图如下：

显然segment节点上的primary和mirro步骤不在一台服务器上，现在的每台服务器上是部署了20个实例，10个primary,10个mirror，总体是交叉的方式。

当然还有一个很重要的步骤也是在并行做，我查看了GP节点的日志，因为涉及的节点有多个，我选取了其中一个，查看pg_log的内容。按照时间戳发现实例产生了宕机，是因为内存溢出导致的。

面对这个问题，快速修复是关键，所以果断使用gprecoverseg来修复。

使用 -o选项来转储文件，得到一个需要恢复的列表。

$ gprecoverseg -o ./recov

然后使用 -i选项来完成节点数据的恢复。

gprecoverseg -i ./recov

到了这个节点之后，其实有部分节点的角色是不对称的，需要调整过来。

可以使用gprecoverseg -r来完成最后的补充工作。

保证了业务节点的正常运行，日志还在，我们来看看日志里的信息，看看后续该怎么改进。

这个日志和之前看到的不大一样，这次是一个内存溢出。

日志信息类似：

One or more query execution processes ran out of memory on this segment. Logging memory usage.",,,,,,,0,,,,

而对应的SQL语句是多个全表扫描的大表，内部做了case when 的关联，一共使用了4个嵌套子查询语句。

这个问题看起来好像很清晰，但是对于GP集群的维护来说，还确实是需要考虑一下资源管理的。