OceanBase幾個常見問題及排查思路

第一種情況：某一台observer挂掉，資料庫異常

OceanBase采用的的是多副本叢集模式，在不同的zone裡面有不同的server，每個zone裡面的server是互相備份的。上層是通過slb來分發是以，當其中一台server挂掉的時候，會對業務産生什麼影響呢？

制造現象：50使用者并發某查詢交易時，kill掉某一台（業務所在的observer跟業務不再的observer）observer。

登入到業務所在的ob伺服器執行以下指令：

預期影響：TPS先掉為0，1分鐘内恢複正常，存在業務失敗。

監控發現：TPS先掉為0，40秒後恢複正常。失敗238筆。

登入到業務不在的observer執行以下指令：

預期影響：對系統沒有影響。

監控發現：交易TPS和響應時間無明顯變化

恢複手段：檢視9台observer的程序，找出挂掉的observer，并使用admin使用者将observer啟動。執行指令如下：

2、伺服器層面占用cpu，資料庫異常

制造現象：将業務所在的observer上的伺服器cpu打滿。

登入到業務所在的observer上的伺服器運作腳本，腳本内容如下：

預期影響：TPS下降，并且伺服器cpu使用率高。

監控發現：TPS由700下降至550，OB CPU使用率90%，保持平穩

恢複手段：可以使用Linux指令找出目前資料庫占用CPU較多的程序，判斷是否重要，将其殺死

3、伺服器層面打滿磁盤，資料庫異常演練

制造現象：将observer所在伺服器的磁盤寫滿

登入到observer伺服器執行指令：

預期影響：TPS降低為0交易持續報錯。

監控發現：TPS由700下降為0，磁盤滿後交易持續報錯共失敗3014筆，交易性能大幅波動

恢複手段：發生這種的影響主要來源于兩個地方，如果這台機器上隻裝了ob以及ob相關的元件的話，寫滿磁盤要麼是資料檔案，要麼是日志檔案，如果是資料檔案，那麼沒辦，隻能擴充資源，如果是日志檔案，找到對應目錄，删除多餘日志檔案。

4、資料庫中存在并發大量爛sql，資料庫異常

制造現象：某正常業務正常運作，這時候并發一個sql比較爛的業務。

預期影響：正常業務TPS下降，并且可能存在失敗現象。

監控發現：批量發起1000個資料庫并發操作，交易TPS立即由700下降至150，同時批量查詢逾時失敗。

恢複手段：sql爛是資料庫的通病，我們可以根據show processlist;檢視目前資料庫目前正在執行的sql，找出執行時間比較久的。然後對其優化，然後根據OceanBase自帶的視圖：gv$sql,gv$sql_audit來看資料庫之前執行過什麼的慢sql對其優化。

5、業務突然增大，并且擴容observer，資料庫異常

制造現象：某業務突然增加50使用者量。之後調整該租戶的cup：alter resource pool xxx_poll unit C12_unit;。

預期影響：并發資料量會産生TPS以及響應時間的上漲，擴充資源會發生抖動，TPS上升，RT下降

監控發現：增加使用者TPS由700上升至800，交易響應時間由0.070上升至0.095秒。擴容資源發生一點點抖動，TPS恢複至800，RT時間恢複到0.095秒。

恢複手段：無

6、模拟資料庫伺服器網絡故障。

制造現象：将observer的2882跟2881端口禁掉

執行指令：

預期現象：TPS會出先下降，然後恢複正常，交易會報錯。

監控發現：TPS先下降一半，1分鐘後恢複正常，交易報錯持續4分鐘。

恢複手段：