宕機前日誌：（分析集群在做什麼）
圖一：
上圖是hbase節點掛掉之前1秒的日誌，由日誌可以看出系統是在做compaction,也就是hbase底層資料原檔案的合併，包括無效資料檔案的刪除，新增資料檔案合併
圖二：
從上邊這幅圖可以看出，同時在做合併刪除的錶不只一張，compaction是非常耗時切工作時很耗資源的操作，並且在做compaction時rs（region server）會掛起一段時間，也就是說hbase對外服務會有延遲，下邊會有說明（特別注意這裡，st_prod也在做compaction，這一點很重要，下邊會有說明）
圖三：
這是官網的截圖，從上邊這句話，官網很委婉的告訴我們，hbase的compaction操作是會造成系統掛掉，建議我們關掉自動的compaction，設定cron job在空閒時做此類操作
圖四：圖四是掛機時丟擲的日誌，是緊接著compaction操作打出的日誌，這時候hbase節點已經掛掉，按理說單單做compaction操作就會讓hbase掛機肯定是不合理的，因為我們的系統每天都在自動做compaction,可是掛機這個時間點很微妙，宕機這幾次都發生在凌晨1.10分左右，幾次宕機時跑的都是toc spark任務的第21步，就是下圖
圖五
這一步是多執行緒的操作（700），這一步是讀取資料的操作，由於讀的資料依然是存在hbase，也就是說這個時間hbase的rs服務同時在做三件高併發的事情，1、外部介面呼叫的請求 2、hbase自身做的compaction 3、toc任務 ,如果單單是高併發，那集群高併發的時候應該也很多，下圖又是導致宕機的乙個關鍵點：
圖六
上圖是spark任務報錯時跑的**，這段sql在從st_prod拉資料，而儲存st_prod的hdfs的檔案訪問都是單程序的（hdfs儲存檔案都是單程序操作），也就是我的底層資料檔案在做compaction操作時，toc任務的read檔案的操作就要等待，而compaction又是乙個很耗時間的操作,所以出現一種情況時，我的toc spark任務起的讀資料的task都在wait，由於一直在等待，zookeeper遲遲得不到返回值，zookeeper發生timeout，zookeeper預設這個hbase節點已經掛掉，最終zookeeper停止對這台hbase節點提供服務，這台hbase節點也就完全掛掉
宕機分析結論：
1、hbase compaction操作在集群訪問頻繁時，有宕機風險 （查閱很多資料都是這個結論，包括官網）
2、特殊情況下的compaction和toc spark任務在操作同一張表，發生等待，導致zookeeper timeout，最終心跳丟失，節點掛掉（目前我們掛機都是在在跑同乙個任務的同乙個步驟）
3、節點在很長一段時間花大精力在做gc，導致gc處在乙個很高的狀態並且持續好久，當然這一步很大程度上也是有1、2步導致
2020 4 29 一場令人頭疼的cf。。。
今天是被安排的cf。我真的是太菜了啊。又雙叒叕被機房的一群dalao吊打了。這就是我與6年級的dalao的區別嗎。我裂開了 t1 a exercising walk 簡單題。就是把移動距離加起來就好了。我居然能寫錯。真的是應該去開一道豬國殺寫寫。鍛鍊鍛鍊碼力。唉t2 b composite colo...
記一次mysql宕機
e warning pdo prepare mysql server has gone away pdo prepare mysql server has gone awayilluminate database queryexception sqlstate hy000 2002 connecti...
jetty發布乙個令人頭疼的問題。
之前的應用遷移一直沒有問題，突然發現乙個應用從jboss遷移到jetty出現bean註冊錯誤，提示bean已經註冊，存在兩份配置檔案。檢視路徑是war中存在乙個xml，tmp jetty xx webinf web inf classes下也有乙個。但是之前的應用為什麼不衝突呢？經駝比較原來之前的應...