datanode启动后闪退_解决了一个Greenplum启动失败的问题

        今天有个其他项目的同事求助，说是他们项目的Greenplum启动不了，让我远程帮忙看看。由于前一阵子我自己也遇到过启动失败的问题并解决了，因此就答应了下来。

      首先连上VPN，登录服务器，切换到gpadmin用户，通过.bash_profile文件找到greenplum的安装目录和master文件路径。然后开始检查日志，查看$MASTER_DATA_DIRECTORY/pg_log下面的startup.log和最新的csv文件，发现没用错误提示。在征询现场的同事后，我觉得重启数据库，看看启动过程中是否有错误提提示。

       从截图可以看到，没有明显的错误提示，只是告知，segment启动失败。既然如此，我们就切换到datanode上面查看segment的日志。在segment的pg_log文件夹下，也是查看最新的csv文件和

      多年的经验告诉我，红色框内的“could not locate a valid checkpoint record”是最重要的线索，于是分别在前面加greenplum和postgresql进行查询。

       在网页https://blog.csdn.net/international24/article/details/89710703找到第一个有用的信息：

       初步断定是由于日志文件损坏，导致启动失败。找到greenplum的安装路径，发现确实提供了pg_resetxlog命令工具。由于这个是postgresql的命令，并且用于window系统，因此我继续百度“greenplum pg_resetxlog” 进一步了解pg_resetxlog命令的用法。搜到的知识很少，只找到另外一篇类似的文章：https://www.bbsmax.com/A/QW5YM9Rq5m/ 。虽然写得更详细，但是帮助不大。

       于是，我先备份好一个segment目录的所有文件，然后执行以下命令：

/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data1/mirror/gpseg5

     根据提示输入yes以后，显示Transcation log reset。

     完成一个节点的修复以后，我尝试重启数据库，结果显示，数据库的6个segment有一个正常启动。这说明我找对了方向。于是又将其它六个segmnet的事务日志重置。

--sdw1/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data1/mirror/gpseg4/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data2/mirror/gpseg5--sdw2/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data1/mirror/gpseg0/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data2/mirror/gpseg1--sdw3/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data1/mirror/gpseg2/usr/local/greenplum-db-6.9.0/bin/pg_resetxlog -f /opt/greenplum/data2/mirror/gpseg3

      完了以后，重启数据库，果然正常启动。

      沟通得知，这次数据库启动异常是由于磁盘空间满了，导致Greenplum数据库down掉，然后重启就出现异常了。

       这里需要说明以下，Greenplum默认是开启读写事务日志的，导致日志增长非常快。但是Greenplum一般都用于OLAP系统，几乎每天全量覆盖数据，所以保留数据修改日志作用不大。一劳永逸的办法就是修改日志参数为只记录DDL日志。命令如下，执行后执行gpstop -u使其生效。

gpconfig -c log_statement -v DDL

        送佛送到西，我帮忙执行了以下这个命令。

        综上，就是我今天帮其他同事解决问题的过程。大概花了一个小时左右。感觉很有成就感，特此总结一下。