GBase新聞
數據庫出現故障時,如何應急處理?別慌,照這樣做(下篇)
當數據庫發生故障時,你會如何進行應急處理?本文通過梳理南大通用GBase 8a數據庫系統使用中可能出現的各種異常情況,以期幫助大家應對GBase 8a數據庫使用中的突發故障,提供基本的問題解決思路。本期續上篇,重點聚焦數據庫服務異常、數據丟失及其他異常等故障類型。
4.數據庫服務異常
4.1 GBase集群服務進程crash
現象描述
集群各節點服務:gclusterd、gbased、gcware、gcrecover、gc_sync_server 5個進程異常crash。
現象分析
集群各節點服務:gclusterd、gbased、gcware、gcrecover、gc_sync_server 5個進程異常crash。
應急操作流程
此種異常大多由于某條SQL或某場景下觸發GBase bug導致,需要通知應用協助排查問題原因。
1)通知開放平臺和GBase廠商協助排查問題。
2)運行部門分析系統中運行的異常SQL。
3)運行部門停止產生問題的SQL。
4)GBase廠商分析該問題場景,提供短期解決方法及后續修復時間。
4.2.GBase集群服務無法啟動
現象描述
集群各節點服務:gclusterd、gbased、gcware、gcrecover、gc_sync_server服務無法啟動。
現象分析
集群各節點服務:gclusterd、gbased、gcware、gcrecover、gc_sync_server 服務無法啟動,通常情況為GBase 8a集群產品bug導致。
應急操作流程
通常情況為GBase 8a集群產品bug導致。
1)運行部門通知開放平臺和GBase廠商協助排查問題。
2)運行部門和GBase廠商分析運行日志及運行場景。
3)GBase廠商分析該問題場景,提供短期解決方法及后續修復時間。
5.數據丟失
5.1.集群中多節點故障,導致集群數據丟失
現象描述
多節點故障,集群數據丟失
現象分析
比較極端的情況下,GBase 8a數據庫多節點故障,導致集群數據丟失,數據無法修復。
應急操作流程
用備份數據進行恢復。
1)通知開放平臺和GBase廠商協助排查問題;
2)運行部門停止運行任務。(10分鐘)
3)GBase廠商停止數據庫服務;
4)GBase廠商從備份介質恢復最近的備份數據;(數據量大小不同,恢復需要的時間差異較大,通常在12-24小時之間)
5)GBase廠商啟動服務,校驗集群數據一致性;(30分鐘)
6)運行部門恢復服務,通知運行部門啟動任務。
6.其他異常
6.1 數據不一致錯誤
現象描述
集群節點出現數據不一致報警
現象分析
某個節點網絡閃斷的情況下,會出現數據不一致的情況,通常會在網絡恢復之后自動進行數據同步。如果長時間處于數據不一致狀態,則需要手工同步數據。
應急操作流程
在網絡恢復的情況下,數據不一致的節點會自動恢復,檢查網絡情況,如果網絡恢復后一個小時數據依然不同步,考慮進行手工同步過程。
1)運行部門通知開放平臺和GBase廠商協助排查問題
2)臨時表加載個別報警可以等待10分鐘,集群自動同步成功,則問題正常結束,否則需要GBase現場支持判斷是否需要停止集群服務,停止運行任務,執行3-6步操作。(取決于當時任務的大小,通常在1小時-4小時之間)
3)GBase 8a停止數據庫服務(20分鐘)
4)GBase廠商分析數據不一致的表,進行手工同步 (根據表大小和不一致的表的數量,時間通常在2-8小時之間)
5)GBase廠商啟動數據庫服務,校驗數據一致性(30分鐘)
6)GBase通知運行部門,系統恢復,啟動任務運行。
6.2數據錯誤
現象描述
某SQL語句執行結果集錯誤。
現象分析
由GBase 8a數據庫執行計劃bug導致SQL語句結果集錯誤。
應急操作流程
如發現此類問題,需應用配合分析目前系統受到的影響范圍及考慮后續修復方法。
1)運行部門通知開放平臺和GBase廠商協助排查問題;
2)GBase廠商分析定位問題,給出詳細原因說明及修復方案、規避方法;
3)應用部門依據廠商說明,分析影響范圍,排查影響范圍;
4)運行部門和GBase廠商修復錯誤數據,并修改程序規避問題。
5)GBase廠商提供修復問題版本。
6.3 執行報錯
現象描述
某SQL語句執行報錯。
現象分析
由GBase 8a數據庫bug導致SQL語句執行報錯。
應急操作流程
如發現此類問題,需責成廠商分析該bug原因,并提供解決期限。
1)通知門通知開放平臺和GBase廠商協助排查問題;
2)Gbase廠商分析并提供規避方案。
3)應用部門依據廠商說明,進行問題規避;
4)GBase廠商提供修復問題版本。
6.4 并發過高導致的數據庫節點負載過高問題
判斷并發過高主要表現在以下幾個方面:
(1)系統CPU使用平均超過90%。
(2)磁盤IO接近飽和。
(3)通過show processlist查看發現并發過高,且有1~3個超長任務(超過或接近1小時)。
解決方法:
1)降低調度系統并發數
2)調整長作業與短作業并發順序,長作業與短作業均勻運行,避免長作業集中運行