Greenplum工具GPCC和GP日志中時間不匹配的實例分析

Greenplum工具GPCC和GP日志中時間不匹配的實例分析，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

今天同事反饋了一個問題，之前看到?jīng)]有太在意，雖然無傷大雅，但是想如果不重視，那么后期要遇到的問題就層出不窮，所以就作為我今天的任務(wù)之一來看看吧。能不能定位和解決，當(dāng)然從事后來看，也算是找到了問題處理的一個通用思路。

問題的現(xiàn)象很明顯：GPCC工具可以顯示出GP的日志內(nèi)容，但是和GP日志里的時間明顯不符。

GPCC的一個截圖如下，簡單來說就好比Oracle的OEM一樣的工具。能夠查看集群的狀態(tài)，做一些基本信息的收集和可視化展現(xiàn)。紅色框圖的部分就是顯示日志中的錯誤信息。

我把日志內(nèi)容放大，方便查看。

以下是從GPCC中截取到的一段內(nèi)容。

截取一段GPCC中的內(nèi)容供參考。

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 <symbol not found> (postgres.c:1811)

10 0x99e9b9 postgres PostgresMain (postgres.c:4760)

11 0x8f8dfe postgres <symbol not found> (postmaster.c:6672)

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 <symbol not found> + 0x4be869

"

根據(jù)時間情況來看，gpcc中顯示的時間明顯比GP日志的要快，認(rèn)真對比了下，按照精度來算，快了14個小時。

還有一個問題是錯誤日志中提到的segment failure是什么意思，是否能給出一個解釋。

所以我們還是得回到GP日志，需要結(jié)合上下文內(nèi)容來做一個理解，回放出在那個時間點的操作。往前看很快就定位到了相關(guān)的日志，原來是在做一批次的copy操作，很可能因為網(wǎng)絡(luò)抖動導(dǎo)致其中一個copy操作阻塞。

所以錯誤信息的基本結(jié)論如下：

通過日志可以明確在GP做copy的過程中很可能出了網(wǎng)絡(luò)問題導(dǎo)致操作受阻，GP嘗試重新連接segment

基本解釋清了問題，我們再來看下本質(zhì)的問題，為什么系統(tǒng)中和日志中的時間戳不同，妥妥的差了14個小時。

所以很自然的，我們會拋出一個問題：數(shù)據(jù)是怎么從日志傳輸?shù)角岸说模?

換個問題就是數(shù)據(jù)是如何從后端傳輸?shù)角岸?，初步的方向就是時區(qū)上面，但是我查看了部署的軟件配置，并沒有關(guān)于時區(qū)的配置。

在咨詢了一些朋友之后，我決定再看看官方是否有相關(guān)的解釋。

花了點力氣，所幸找到一篇，還是在3月底更新的一篇，這個時候碰到這個問題算是很應(yīng)景了。

話外音就是搜索還是要講究點技巧，要不搜索不出來確實很尷尬。官方的建議，其實就是因為時區(qū)的特定設(shè)置，也可以理解是一個bug,在實現(xiàn)的時候，對于中文支持的原因?qū)е铝诉@個問題，如果要做一個WA，可以重置GPCC的檔案庫和用戶的timezone，當(dāng)然還需要重啟GP集群生效，修改后的日期時間戳就顯示不是CST,而是HKT，可能還需要評估下是否有其他的影響范圍。

所以對于時間問題不一致的基本結(jié)論如下：

這個是GPCC的一個問題，在3.x版本出現(xiàn)，在低版本也是同樣的。

要修復(fù)這個問題，需要重新設(shè)置時區(qū)的配置，重新GP集群，可以考慮后續(xù)是否有機(jī)會來做下這個問題的修復(fù)。前提還是在測試環(huán)境充分測試驗證。目前先保持現(xiàn)狀。

看完上述內(nèi)容，你們掌握Greenplum工具GPCC和GP日志中時間不匹配的實例分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！