Greenplum 6.x某些版本中存在COPY语句导致Segment挂掉的BUG

今天给大家分享一个Greenplum 6.x某些版本的bug吧,这个事情的起因是有朋友问过来说有个GPCC的dat数据文件特别特别的大,问怎么处理。

朋友发过来的文件信息如下:

-rw-r--r--  1 gpadmin gpadmin 1210206598517 Jan  4 21:38 gpcc_queryinfo_2022-01-04_181758.dat
-rw-r--r--  1 gpadmin gpadmin  298794041344 Jan  5 05:00 gpcc_queryinfo.dat

总体来看,有两个dat数据文件,在gpcc中,dat文件是用于存储gpcc当前数据的临时文件,这些文件通常位于greenplum-cc-web-6.1.0/ccdata/路径下,Greenplum通过外部表的方式关联到文件并做实事查询。当文件不具有当前属性以后,会通过copy命令直接入库到gpcc对应数据库的history表中进行存储。当然这两个文件有点大,由于没有获取到具体的数据库版本信息和gpcc信息,所以我还是建议他们删除要慎重。

建议他们慎重处理是因为Greenplum 6.x有一个bug,gpcc的文件copy入库可能导致segment直接挂掉,下面展开给大家介绍一下这个bug。当然这个bug并不是GPCC的坑,以上内容只是个引子。

BUG名称:COPY导致的Greenplum 6.x版本Segment异常挂掉

该问题出现在Greenplum 6.0 - 6.7.1版本上,如果你在这些版本的数据库上使用GPCC 4.x及以上的版本,从数据库的pg_logs日志中可能看到如下错误信息:

2020-09-18 12:34:04.253914 EDT,,,p304924,th0,,,2020-09-18 12:26:44 EDT,0,con504392,cmd240,seg18,,,,,"PANIC","XX000","Unexpected internal error: Segment process received signal SIGSEGV",,,,,,,0,,,,"1    0x7f213debe630 libpthread.so.0 <symbol not found> + 0x3debe630
2    0x829eac postgres <symbol not found> (copy.c:5456)
3    0x82fd94 postgres <symbol not found> (copy.c:3904)
4    0x833e30 postgres DoCopy (copy.c:1129)
5    0xa87105 postgres standard_ProcessUtility (utility.c:637)
6    0xa83711 postgres <symbol not found> (palloc.h:158)
7    0xa8420e postgres <symbol not found> (pquery.c:1512)
8    0xa85927 postgres PortalRun (pquery.c:1022)
9    0xa7de1e postgres <symbol not found> (postgres.c:1377)
10   0xa82a58 postgres PostgresMain (postgres.c:5403)
"

当你在master或segment的日志中发现这个问题时,可以尝试追踪一下con<session_id>信息来判断是哪个查询引起了该问题。在上面的日志中,引起问题的查询连接为con504392。通过进一步的查询定位,发现是gpsmon用户导致的,它正在执行的语句为:

COPY gpmetrics.gpcc_queries_history FROM '/usr/local/greenplum-db/greenplum-cc-web-6.1.0/ccdata/gpcc_queryinfo_2020-09-18_123403.dat' ESCAPE E'\\\\' CSV NULL AS E'null' DELIMITER E'|' LOG ERRORS SEGMENT REJECT LIMIT 100 PERCENT;

最后总结一下,当前该BUG的出现是由于GPCC执行COPY语句导致的,但是这并不是一个针对GPCC单独的BUG。也就是说,在所有的COPY语句执行过程中,都有可能出现该问题,只是因为GPCC碰巧会频繁的执行COPY语句而触发了该问题,该错误的具体原因是:在单行错误验证模式下执行COPY FROM命令向分区表插入数据时,数据文件中存在错误格式的数据,QE不能很好的处理数据格式错误。所以大家如果遇到该问题,还是要建议规避或尽快修复。

解决方案

该BUG在Greenplum 6.8.0版本上被修复了。如果你遇到了该问题,建议尽快升级到 6.8或以上的版本。你也可以通过停止使用GPCC并在你自己的应用里面把COPY语句改为其他入库方式来规避该问题,但是还是建议尽快升级。


版权声明:本文为chrisy521原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。