摘要：先通過OPS確認節點狀態是否已經恢復，或登錄后臺執行cm_ctl query -Cv確認集群是否已經Normal，
本文分享自華為云社區《【實體狀態】GaussDB CN服務例外》，作者：酷哥，
確認節點狀態
先通過OPS確認節點狀態是否已經恢復，或登錄后臺執行cm_ctl query -Cv確認集群是否已經Normal，如果狀態已經為normal，表明故障已經恢復，集群正常，不再影響業務， 確認是否需要分析故障的具體原因，如果需要，繼續向下跟隨檔案進行分析 首先確認是否是底層故障如虛擬機故障、網路故障、存盤故障，排除底層故障后再繼續定位，
定位導圖總覽
CN行程normal
問題現象
cm_ctl query -Cvd 查詢集群狀態，告警CN顯示normal，
問題分析與定界
step1. 登錄告警CN節點，su 進入集群用戶，ps ux | grep 'gaussdb --coordinator'，查看CN行程啟動時間，確認CN是否重啟，如果沒有重啟參考處理方法一（結束），若重啟則跳至step2
step2. cd $GAUSSLOG/cm/cm_agent
step3. 打開對應時間點的vi cm_agent-*.log
step4. 查看日志中對應時間點是否含有關鍵詞 cn restart，如果同時有process (gaussdb 17391) is T (STOPPED) 類似日志，說明行程hang住了，跳至step6
step5. 若日志中沒有cn restart關鍵詞，查看日志中對應時間點是否含有關鍵詞 CN START.有則跳至step10
step6. 登錄到CMS主節點 cd $GAUSSLOG/cm/cm_server
step7. 打開對應時間點的cm_server*.log
step8. 查看日志中對應時間點是否含有關鍵詞 restart %u, there is not report msg for %d sec. 如果有，則CN重啟原因為心跳超時，參考處理步驟方法一（結束 ）
step9. 查看日志中對應時間點是否含有關鍵詞 phony dead times (%d) already exceeded, will restart...則CN重啟原因為行程僵死，參考處理步驟方法一（結束）
step10. cd $GAUSSLOG/cm/cm_agent,打開對應時間點的system_call-*.log,查看對應時間點是否有關鍵詞can not bind ip，如果沒有則跳至step12
step11. 如果有關鍵詞can not bind ip，則CN重啟原因為CN IP丟失，參考處理步驟方法二 （結束）
step12. cd $GAUSSLOG/pg_log/cn_XX
step13. 查看相關postgresql_xxx.log, 查看相關時間點是否有關鍵詞PANIC，如果有則原因為core，參考處理步驟方法一，
step14. 查看CN資料目錄下是否有core生成，如果有則原因為core，參考處理步驟方法一，
step15. 查看$GAUSSLOG/ffic_log日志，查看對應時間點是否有列印日志，如果有則原因為core，參考處理步驟方法一，
處理步驟
方法一：聯系華為工程師進行定位
方法二：檢查故障節點虛擬IP，浮動IP，如有問題，請排查管控HA是否關閉，
CN行程down
問題現象
cm_ctl query -Cvd 查詢集群狀態，告警CN顯示down，
問題分析與定界
step1. cd $GAUSSLOG/cm/cm_agent
step2. 打開對應時間點的cm_agent-*.log
step3. 查看日志中對應時間點是否含有關鍵詞 cn_disk_damage=1，如果有，則原因為資料/日志磁盤損壞或磁盤滿，參考處理步驟方法一，
step4. 查看日志中對應時間點是否含有關鍵詞 port_conflict=1，如果有，則原因為埠沖突，參考處理步驟方法二，
step5. 查看日志中對應時間點是否含有關鍵詞 cn_nic_down=1，如果有，則原因為網卡故障，參考處理步驟方法三，
step6. 查看日志中對應時間點是否含有關鍵詞 cn_manual_stop=1，如果有，則原因為手動停止，參考處理步驟方法四，
處理步驟
方法一：查看對應故障cn的磁盤是否有故障，如無故障則檢查是否磁盤滿，
方法二：lsof -i:埠號，查看埠占用行程，聯系華為工程師定位處理
方法三：聯系I層查看是否存在網卡故障
方法四：查看是否有人手動停止
CN行程deleted
問題現象
cm_ctl query -Cvd 查詢集群狀態，告警CN顯示deleted，
問題分析與定界
step1. 確認當時時間故障CN所在節點是否正常，是否主機故障，重啟、掉電，斷網等，參考處理步驟方法一，
step2. 登入CMS主節點，cd $GAUSSLOG/cm/cm_server，打開對應時間點的cm_server*.log
step3. 如果日志中有關鍵詞isCnDnDisconnected=1, 則原因為CN與所有主DN斷連，參考處理步驟方法二，
step4. 如果日志中有關鍵詞cn_down_to_delete=1,則原因為CNdown 導致，參考處理步驟方法三，
step5. 如果日志中有關鍵詞cn instance restarts within ten minutes is more than,則原因為CN進行重啟 導致，參考處理步驟方法四，
處理步驟
方法一：聯系I層查看主機故障原因，排除故障后，在管控點擊節點修復修復cn節點，
方法二：在管控點擊[節點修復]修復cn節點，聯系華為工程師處理
方法三：在管控點擊[節點修復]修復cn節點，參考第二章CN DOWN進行定位
方法四：在管控點擊[節點修復]修復cn節點，參考第一章CN NORMAL進行定位
CN行程readonly
問題現象
cm_ctl query -Cvd 查詢集群狀態，告警CN顯示readonly，
問題分析與定界
step1. 登錄到只讀CN節點后，su - Ruby進入Ruby用戶， 執行/usr/sbin/chroot --userspec=Ruby:Ruby /var/chroot 進入沙箱，source /etc/profile設定環境變數
step2. df -h 查看磁盤空間分配情況，cm_ctl query -Cvd查看CN資料目錄路徑，確認所在磁盤空間使用率，
step3. 登陸cmserver主節點，進入cmserver資料目錄/var/chroot/usr/local/cm/cm_server，查看cm_server.conf 組態檔，查看引數datastorage_threshold_value_check的值，當磁盤使用率超過該引數值時，CN就會被設定為只讀，避免磁盤被寫滿，比較CN磁盤使用率是否超過該引數值，如果是，則按照處理步驟1處理，如果否，則按照步驟2處理
處理步驟
1、聯系華為工程師，確定是否需要擴容或者洗掉同磁盤的無用檔案
2、參考CN只讀處理方法
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/536154.html
標籤：其他