Greenplum工具GPCC和GP日志中时间不匹配的实例分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
网站建设公司,为您提供网站建设,网站制作,网页设计及定制网站建设服务,专注于企业网站制作,高端网页制作,对成都葡萄架等多个行业拥有丰富的网站建设经验的网站建设公司。专业网站设计,网站优化推广哪家好,专业营销推广优化,H5建站,响应式网站。
今天同事反馈了一个问题，之前看到没有太在意，虽然无伤大雅，但是想如果不重视，那么后期要遇到的问题就层出不穷，所以就作为我今天的任务之一来看看吧。能不能定位和解决，当然从事后来看，也算是找到了问题处理的一个通用思路。
问题的现象很明显：GPCC工具可以显示出GP的日志内容，但是和GP日志里的时间明显不符。
GPCC的一个截图如下，简单来说就好比Oracle的OEM一样的工具。能够查看集群的状态，做一些基本信息的收集和可视化展现。红色框图的部分就是显示日志中的错误信息。
我把日志内容放大，方便查看。
以下是从GPCC中截取到的一段内容。
截取一段GPCC中的内容供参考。
03 Apr14:18:07
ERROR
MPP detected 1 segment failures, system is reconnected (cdbfts.c:228)
u:datax_userdb:TESTDB host:10.xxxx
而GP的日志显示如下：
2018-04-03 00:18:07.055801 CST,
"datax_user","TESTDB",p173295,th972601120,"10.xxxx","64523",2018-04-03 00:17:40 CST,1811909,con659620,cmd1,seg-1,,dx572994,x1811909,sx1,"ERROR","XX000","MPP detected 1 segment failures, system is reconnected (cdbfts.c:228)",,,,,"COPY test_map, line 11705805: ""20150826|38377|5364390|1|1|1|1|1|1|1|1|1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|2018-04-03 00:1.
..""","COPY test.test_map ( xxxx) FROM STDIN delimiter as '|' NULL 'null' ",0,,"cdbfts.c",228,"Stack trace:
1 0xb0aefe postgres errstart (elog.c:502)
2 0xc29d9f postgres FtsHandleNetFailure (cdbfts.c:227)
3 0xbd4ca5 postgres cdbCopyEndAndFetchRejectNum (cdbcopy.c:804)
4 0x6b757a postgres CopyFromDispatch (copy.c:3823)
5 0x6c6c9c postgres DoCopyInternal (copy.c:1767)
6 0x6c8388 postgres DoCopy (copy.c:1883)
7 0x9a5f9d postgres ProcessUtility (utility.c:1100)
8 0x9a364b postgres PortalRun (pquery.c:1505)
9 0x99a5bc postgres
10 0x99e9b9 postgres PostgresMain (postgres.c:4760)
11 0x8f8dfe postgres
12 0x8fba90 postgres PostmasterMain (postmaster.c:7603)
13 0x7fbeff postgres main (main.c:206)
14 0x37f901ed1d libc.so.6 __libc_start_main + 0xfd
15 0x4be869 postgres
"
根据时间情况来看，gpcc中显示的时间明显比GP日志的要快，认真对比了下，按照精度来算，快了14个小时。
还有一个问题是错误日志中提到的segment failure是什么意思，是否能给出一个解释。
所以我们还是得回到GP日志，需要结合上下文内容来做一个理解，回放出在那个时间点的操作。往前看很快就定位到了相关的日志，原来是在做一批次的copy操作，很可能因为网络抖动导致其中一个copy操作阻塞。
所以错误信息的基本结论如下：
通过日志可以明确在GP做copy的过程中很可能出了网络问题导致操作受阻，GP尝试重新连接segment
基本解释清了问题，我们再来看下本质的问题，为什么系统中和日志中的时间戳不同，妥妥的差了14个小时。
所以很自然的，我们会抛出一个问题：数据是怎么从日志传输到前端的？
换个问题就是数据是如何从后端传输到前端，初步的方向就是时区上面，但是我查看了部署的软件配置，并没有关于时区的配置。
在咨询了一些朋友之后，我决定再看看官方是否有相关的解释。
花了点力气，所幸找到一篇，还是在3月底更新的一篇，这个时候碰到这个问题算是很应景了。
话外音就是搜索还是要讲究点技巧，要不搜索不出来确实很尴尬。官方的建议，其实就是因为时区的特定设置，也可以理解是一个bug,在实现的时候，对于中文支持的原因导致了这个问题，如果要做一个WA，可以重置GPCC的档案库和用户的timezone，当然还需要重启GP集群生效，修改后的日期时间戳就显示不是CST,而是HKT，可能还需要评估下是否有其他的影响范围。
所以对于时间问题不一致的基本结论如下：
这个是GPCC的一个问题，在3.x版本出现，在低版本也是同样的。
要修复这个问题，需要重新设置时区的配置，重新GP集群，可以考虑后续是否有机会来做下这个问题的修复。前提还是在测试环境充分测试验证。目前先保持现状。
看完上述内容，你们掌握Greenplum工具GPCC和GP日志中时间不匹配的实例分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！