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

第一種情況：

某一台observer掛掉，資料庫異常

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

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

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

ps -ef|grep observer;kill -9 pid

預期影響：tps先掉為0，1分鐘內恢復正常，存在業務失敗。

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

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

ps -ef|grep observer;kill -9 pid

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

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

恢復手段：檢視9臺observer的程序，找出掛掉的observer，並使用admin使用者將observer啟動。執行命令如下：

su - admin;/bin/observer

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

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

登入到業務所在的observer上的伺服器執行指令碼，指令碼內容如下：

#! /bin/bash
# filename killcpu.sh
endless_loop()
if [ $# != 1 ] ; then
echo "usage: $0 "
exit 1;
fifor i in `seq $1`
do endless_loop
pid_array[$i]=$! ;
done
for i in "$"; do
echo 'kill ' $i ';';
done
#執行命令：./killcpu.sh 30 
#引數位占用幾顆cpu 核數

預期影響：tps下降，並且伺服器cpu利用率高。

監控發現：tps由700下降至550，ob cpu利用率90%，保持平穩

恢復手段：可以使用linux命令找出當前資料庫占用cpu較多的程序，判斷是否重要，將其殺死

ps -aux | sort -k4nr | head -n

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

製造現象：將observer所在伺服器的磁碟寫滿

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

dd if=/dev/zero of=/home/admin/oceanbase/log/1.log bs=100k count=1600000

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

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

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

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

製造現象：某正常業務正常執行，這時候併發乙個sql比較爛的業務。

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

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

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

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

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

預期影響：併發資料量會產生tps以及響應時間的**，擴充資源會發生抖動，tps上公升，rt下降

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

恢復手段：無

6、模擬資料庫伺服器網路故障。

製造現象：將observer的2882跟2881埠禁掉

執行命令：

iptables -a input -i bond0 -p tcp --dport 2882 -j drop iptables -a input -i bond0 -p tcp --dport 2881 -j drop iptables -a output -p tcp --dport 2882 -j drop

iptables -a output -p tcp --dport 2881 -j drop

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

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

恢復手段：

iptables -d input 1 iptables -d input 1 iptables -d output 1

iptables -d output 1

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

網球線的幾個常見問題

常見問題朗動常見問題

關於Web專案編譯的幾個常見問題

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

網球線的幾個常見問題

常見問題 朗動常見問題

關於Web專案編譯的幾個常見問題

相關推薦

常見問題朗動常見問題