批量查询preparedstatement只需要最后关闭还是每次都关闭_Shit！Greenplum变成一个只进不出的“貔貅”？原来是这个原因...

       最近踩了一个greenplum的坑，简单记录一下。在客户的小型私有云环境，搭了两个环境的greenplun集群，开发环境是单机版，一台32G服务器上部署了master节点和4个segment；生产环境给了三台服务器，主节点32G，两个数据节点64G(PS:我一直认为Greenplum的mirror节点太过冗余了，消耗一半的硬件资源还不一定能起到高可用的效果！欢迎读者留言怼我)，于是我就安装部署了Greenplum环境，数据节点上各安装了4个segment(这边客户数据量还在百万级别，很少过千万，所以我觉得4个够用了)。其实十一之前就安装好了，相关配置参数也调整好了，只是程序还在开发中，数据未迁入。期间多次重启数据库，一切正常。

        上周开始迁移数据，然后让我怀疑人生的事情就发生了。我把测试环境的表结构和数据全部迁移到生产环境以后，生产环境的查询竟然完全进行不下去。不管是在客户端软件，还是在命令行，不管是百万计的表，还是十几条记录的表，只要执行查询语句，数据库就不给响应。一开始，我以为是数据刚迁移，数据库还在进行数据平衡操作，奈何过了一个周末，情况还是如此。我删除表，重建表结构并insert数据，过程完全正常！我彻底震惊了，Greenplum变成了一个吃数据库的黑洞，哈哈，大脑里就想到了每次旅游都被购物点安利的上古神兽“貔貅”——“貔貅龙生九子之一,吃东西只进不出”。

        千辛万苦，找到一点警告，于是只能拿这个警告去百度，网上的说法，无外乎，网络不稳定，改成tcp链接。为了方便其他人遇到相同错误找到这篇文章，我把错误贴在这里吧。

greepplum "Interconnect encountered a network error, please check your network (seg1 slice1 机器名:端口 pid=7488)","Failed to send packet (seq 1) to IP:端口 (pid 5582 cid 3) after 3581 retries in 3600 seconds"

        搞了好久，问题还是没解决，于是发微信群求助。就在下班发出求助，回家的路上，我突然茅塞顿开了，根据错误提示，应该是网络问题，难道是因为防火墙？！说起来也是有些奇怪，为什么我最开始就怀疑是网络不通，但是一直没有检查防火墙呢？因为我从头到尾都没有调整防火墙策略，但是重启和数据插入都需要通信端口开通才可以，但是以上这些操作都没有被防火墙拦截，为毛查询会被拦截？！然而，现实就是这么残酷，当我关闭防火墙以后，一切不合理的症状就都消失了。

         最后总结一下，Greenplum集群部署，一定要关闭防火墙！不要问为什么，我已经踩过坑了。

       最后的最后，我补充一个这之前遇到的坑，有一次我重启数据库，结果数据库启动失败，但是启动日志startup.log里面却没有错误。最后我在/data/greenplum/greenplum-data/master/gpseg-1/pg_log目录下的和启动时间相同的csv文件中才找到错误！

[root@gpmaster pg_log]# cat gpdb-2020-10-13_132344.csv

2020-10-13 13:23:44.622214 CST,,,p8107,th-1059575680,,,,0,,,seg-1,,,,,"LOG","F0000","invalid authentication method ""127.0.0.1/32""",,,,,"line 99 of configuration file ""/data/greenplum/greenplum-data/master/gpseg-1/pg_hba.conf""",,0,,"hba.c",1206,

2020-10-13 13:23:44.622341 CST,,,p8107,th-1059575680,,,,0,,,seg-1,,,,,"FATAL","F0000","could not load pg_hba.conf",,,,,,,0,,"postmaster.c",1470,

    找到错误，解决起来就很简单了，我的错误是由于pg_hba.conf错误的配置了127.0.0.1/32的ip地址信息。