【GreenPlum节点异常分析】

发生场景：
2024年7月9日 8:34，邮件收到GreenPlum数据库部分数据节点down掉的GPCC监控报警。

处理方式：
1、通过执行 gpstate -m ，显示镜像实例同步状态。

Data Status若为Synchronized，表示主备上的数据都是最新的。

Data Status若为Synchroning，表示节点实例正在同步数据中。

下图中可见Data Status为Not In Sync，表明此mirror节点已被激活。

2、通过执行 gpstate -c，显示主镜像映射，记录该mirror节点对应的primary节点目录

3、执行数据库自带恢复工具 gprecoverseg，执行 gprecoverseg -r ，进行节点数据重平衡，节点成功恢复正常，耗时10min。
 

原因分析：
1、排查主节点相关日志，发现8:17分左右，日志报错连接数不够。

2、查看上述记录的primary节点日志，发现该时期也在报连接数不够的异常。

3、查看GPCC通知报错，发现8:26分segment_2宕机了，执行 gpstate -s 查看 segment_2 对应的目录日志，发现在报连接数不足后，一个数据库自身的数据同步的 copy 操作因为无法开启事务而发生异常，导致该节点宕机。报错日志如下：

结论：节点宕机的原因是子节点连接数过多，导致数据库主从同步事务(COPY)无法正常建立连接，最终子节点宕机。

为防止再次发生，执行以下措施：

调整 max_connections 的参数值，将子节点的连接数从2500增加至3000。