greenplum问题排查思路

1.gp服务无法重启

问题背景 ,客户数据抽取失败,登录gp服务器gpstate -s看不了状态,gpstop停止不了服务

登录gp服务器master节点

su - gpadmin

#使用gpstop -r -M fast会报错

#报连接数太多的信息,无法重启。

处理办法:

ps aux|grep 5432|grep startup

过滤出占用5432端口的startup进程,然后kill -9 其中一个pid

2.数据抽取全部失败

问题背景:客户的抽取任务全部失败,查看详情发现连不上数据库,怀疑是gp服务的问题

登录gp服务的master服务器

su - gpadmin

gpstate -s

发现状态都没啥问题

排查发现gp的segment节点磁盘都打满了,原因是数据存放目录的pg_log目录日志数据占用磁盘空间过多

如何查看segment的数据存放目录:

master节点gpstate -s命令输出会显示segment节点的数据目录

如下图所示:

然后登录对应的segment节点,进入到数据目录,会有pg_log的目录

du -sh pg_log 发现占用很大空间

然后rm -rf一个月之前的日志,格式为.csv后缀的文件

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/05/dd8aebdfaf52444796c55c47a9887c6b.png

如何查看master节点的数据目录:

cat /home/gpadmin/.bashrc

MASTER_DATA_DIRECTORY字段为master数据目录,进入pg_log目录,也可以清理master节点的日志。

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/05/8b4f10a633bb414d8f606abf80250064.png

还有一种情况就是连接数过多,也会导致gp服务异常从而导致抽取失败。

前端报错如下:

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/18/2e67da97583649c7bd937bdd62cd1485.png

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/18/3b7c939acdea4c43ab0259f2c23f605d.png

查看pgbouncer日志会发现有如下报错:

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/18/3ee77d7078e84f229a15dc93423dc8ca.png

查看master日志,有如下报错:

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/18/c1f8bf8726a54ea5a2e58e0ad458df71.png

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/18/c2c656fdd04b41e0b2b4977a831891d5.png

解决方法:重启下gp服务

如果有报主进程还在的报错,gpstart 没法启动,ps -ef |grep postgres,找到有master字段的进程,kill掉。

然后再gpstart -a启动gp服务。

pgbouncer也可以重启下,kill掉之前的pgbouncer进程,然后再进入pgbouncer目录,./pgbouncer -d pgbouncer.ini

这种情况可以给客户添加大查询清理脚本加入到计划任务中。

脚本内容参考如下文档维护配置章节:

【对外】网易有数MPP安装部署手册

3. 数据抽取全部加载中

问题背景:客户gp服务器重启,gp服务并未启动,需要手动拉起(其中一个方面,不是说全部加载中一定是这个原因

启动的命令以及gp基础运维命令如下:

登录master节点

su - gpadmin

gpstate -s #查看gp集群节点的状态信息

也可以psql youdata

执行select 1 from gp_dist_random('gp_id');

返回都是1,就是没问题的。

gpstop -M fast -a #快速停止gp服务,并不用人工确认

gpstart -a #启动gp服务,并不用人工确认

gpstop -r #重启gp服务

gpstop -u #修改了pg\_hba.conf配置文件,需要生效

gpstart -m # 维护模式只启动master节点

gpstop -mr # 完成维护工作后,将gp重启为正常状态

重新拉起pgbouncer

ps -ef|grep pgbouncer #过滤出目前的pgbouncer进程号

kill -9 过滤出的PID

进入创建的pgbouncer文件夹下面执行./pgbouncer -d pgbouncer.ini

如果忘了pgbouncer文件夹放在哪

find / -name "pgbouncer"

会返回出pgbouncer的目录路径

关于gp的高可用配置以及恢复可以参考下面的文档:

greenplum高可用配置以及测试恢复

关于gp的元数据清理操作,可以参考下面的文档:

greenplum 元数据表深度整理

4. gp节点的状态不是UP,如何恢复

登录master节点,gpstate -s返回结果,segment节点有DOWN的状态

先重启gp服务

gpstop -r

如果还有down的状态

gprecoverseg

这个命令会恢复集群中segment节点的状态,前提是数据目录等数据都没问题,且可以正常通信

可以参考如下文档:

GreenPlum运维手册.docx

5. 如何添加用户访问gp数据库,并且可以通过数据库工具连接

问题背景:杭州银行客户新建了一个youdata_prd库,在pg_hba.conf 文件里新增了youdata用户访问youdata_prd库权限,但是没有生效,并且通过navicat连接工具使用youdata用户连接youdata_prd库连不上。

处理方案:

pg_hba.conf配置文件下方需要添加youdata访问youdata_prd库的白名单,然后gpstop -u使其配置文件生效。

文件内容参考如下:

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/05/86be3f1b2fe84683978c913717842770.jpg

然后将pgbouncer目录下的pgbouncer.ini和pg_hba文件内容添加这个库的信息

pg_hba文件内容参考如下:(如果不用youdata_insert和youdata_admin用户连接的话,可以忽略,不用添加配置

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/05/e71372a9e6874363a1e0e686d235a803.jpg

然后添加pgbouncer.ini文件最上方的databases字段,和youdata保持一致

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/05/9bd38e2639034fc2ac692d0543896d18.jpg

最后把之前的pgbouncer进程杀了然后./pgbouncer -d pgbouncer.ini 重新拉起pgbouncer进程,就可以了。

如果杀不了进程可以 ./pgbouncer -R pgbouncer.ini 重新读取配置文件

6. gpstart启动会卡住

场景:客户gp服务器挂了,然后重启机器,gp服务起不来

解决方法:此场景之前从没遇见过,

gpstate -s查看状态会发现5432端口没起来

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/16/f4baf14addfd477e838c467450d1afb8.png

gpstart 会卡住,怀疑是master数据目录数据没有加载。

ps aux|grep start 会显示一个进程,比如/app/data/master/gpseg-1/pg_log/startup.log ,

然后查看startup.log文件内容,查看最后几十行,会发现有明显报错:/app/data/master/gpseg-1 should be 0700 rwx------, 发现master数据目录的权限不是700导致master数据没法加载而导致gpstart 会卡住。将其目录权限设置为700,chmod -R 700 gpseg-1。

segment数据目录同样如此,将/app/data/下的primary1,2,3,xxx,至于有多少个就看下对应环境下有多少,然后下面的gpseg0,1,xxxx目录权限都设置为700,chmod -R 700 gpseg0,1,x,xxx.

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/16/046bd0f6a3fb4343bf6d638daa60b452.png

权限都改完后,ps aux|grep start,得到下方的所有进程,都kill掉,kill -9 $PID

知道ps aux|grep start下方没有进程了,再gpstart -a 启动gp服务,然后就没有卡住的现象了。

启动完后gpstate -s查看状态也都是UP,然后启动pgbouncer连接池

cd /app/pgbouncer, ./pgbouncer -d pgbouncer.ini

https://office.netease.com/api/admin/file/download?path=cowork/2024/07/16/a65521082e4b43d394a0e338f2fe48c0.png

然后让客户验证抽取也没问题。

7.磁盘清理方案

gp的segment节点磁盘都打满了,原因是数据存放目录的pg_log目录日志数据占用磁盘空间过多

如何查看segment的数据存放目录:

master节点gpstate -s命令输出会显示segment节点的数据目录

如下图所示:

然后登录对应的segment节点,进入到数据目录,会有pg_log的目录

du -sh pg_log 发现占用很大空间

然后rm -rf一个月之前的日志,格式为.csv后缀的文件。

如果是master节点磁盘快打满了,cat /home/gpadmin/.bashrc会有MASTER_DATA_DIRECTORY数据目录,进入后会有pg_log目录,删除一个月之前的.csv文件。

8.名创优品重启机器导致gp可读不可写

现象:

gp服务启停正常,gpstate -s 各segment都up,查询gp_dist_random表中各状态正常,后续排查为在/etc/hosts下增加了一行127.0.0.1的解析导致gp可读不可写

https://office.netease.com/api/admin/file/download?path=cowork/2024/08/05/faf6a18b1be445e1bf99acdd2d9bd1ff.png

https://office.netease.com/api/admin/file/download?path=cowork/2024/08/05/3636634cc1364b8bb0ed054afb52c4ee.jpg