資訊專欄INFORMATION COLUMN
點擊上方“IT那活兒”，關注后了解更多內容，不管IT什么活兒，干就完了！！！
環境描述
名稱：操作系統
版本：Linux version：redhat 7.4
名稱：Greenplum
版本：Database:greenplum4.3.30.4
問題描述
在生產環境中我們所維護的greenplum集群偶爾會遇到segments節點實例宕停的情況，導致實例宕停的因素比較多。
如：硬件上的磁盤故障導致io較高，內網的網絡波動。sql語法的不規范導致資源消耗過大，大批量的調度語句集中在一個時間點導致集群壓力太大。相關參數上的設置過小等等.....
這樣的原因都會導致集群某一個或多個mirrror實例在固定的時間點宕機，以上的情況一般不會導致primary宕機，但是也不一定遇到primary也可以按照以下方法排查原因。
排查方法
1. 排查是否是硬件的問題，查看主機日志messages
路徑：/var/log/messages
查看是否是降級導致的，磁盤降級的關鍵詞根據主機廠商不同一般不一樣。
如果是內存或者別的硬件導致的就執行以下命令（如果是硬件導致可能會有primary實例宕停）。
cat /var/log/messages | grep ker具體的報錯信息需根據經驗判斷。
gpstate -e可以看到主機名后面的就是宕停實例的目錄路徑。
登錄gp2切換到pg_log目錄下：
可以看到按日期生成的.csv文件，這就是數據庫日志。
但是有的文件后綴不是000000，是為什么？
數據庫日志文件本身就是“gpdb-年-月-日_時間“，顯示000000是因為在凌晨12點整生成的，而那些不是000000的則是因為該實例宕停不在記錄日志信息只有把實例拉起時才會繼續記錄，而拉起宕停實例的時間就會自動生成一個對應的.csv文件。
查看相應的日志文件可以看到紅色標記的哪一行有“WARING“關鍵詞，而后面的信息就是當該實例宕停時所打印的信息。而報錯信息的大概意思就是”在連接時收到了關閉信息并且成功了“，為什么會導致這樣的情況？
根據網上得到的方案可以修改的參數有這兩個：
這個參數簡單的說就是在Master和Segment之間的探測超時時長。
導致的原因可能時那個時間點集群的壓力過大，通信超時，可以將時間調高點。
這里引用greenplum6.0.1的解釋：
3. sql語句的原因
這里就需要在master主機部署一個記錄集群會話的腳本，將宕機時間點的sql反饋給應用讓他們檢查是否有問題，或者將宕機時間點的會話分散執行。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129540.html
摘要：下安裝配置文檔一系統要求系統版本要求根據官方文檔支持以下幾種系統文件系統要求數據存儲目錄為文件系統二下安裝服務器列表主節點數據節點數據節點主節點切換備用節點修改系統配置項關閉關閉防火墻修改內核配置參數并執行使之生 centos7.3下 greenplum-db 安裝、配置文檔 一.系統要求 1.系統版本要求:根據官方文檔： greenplumd-b支持以下幾種linux系統: ...
摘要：上有主節點和從節點兩部分，兩者主要的功能是生成查詢計劃并派發，以及協調并行計算，同時在上保存著，這個全局目錄存著一組數據庫系統本身所具有的元數據的系統表。 前言：近年來，互聯網的快速發展積累了海量大數據，而在這些大數據的處理上，不同技術棧所具備的性能也有所不同，如何快速有效地處理這些龐大的數據倉，成為很多運營者為之苦惱的問題！隨著Greenplum的異軍突起，以往大數據倉庫所面臨的很多...
摘要：冒煙類型測試冒煙測試這個術語的定義一系列初步的測試來揭示一些簡單的故障的嚴重性，以此來拒絕預期中軟件的發布。冒煙測試最頻繁的特點就是它運行的很快，通常是秒級的。 Satellite是硅谷初創公司Gravitational公司旗下一個用Go寫的開源項目，可用來收集Kubernetes集群的健康信息，它既是一個library，也是一個應用。作為library，可以用做監控方案。在這篇文章里...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1904·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2751·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
