【故障公告】再次出現數據庫 CPU 居高不下的問題以及找到了最可能的原因
阿新 • • 發佈:2019-09-07
非常非常抱歉,今天上午的故障又一次給大家帶來麻煩了,再次懇請大家的諒解。
在昨天升級阿里雲 RDS SQL Server 例項的配置後(詳見昨天的博文),萬萬沒有想到,今天上午更高配置的阿里雲 RDS 例項依然出現了 CPU 居高不下的問題。
在資料庫 CPU 高的情況下,有時對訪問速度影響不大,有時巨慢無邊,在今天上午的故障期間,我們通過2次主備切換才恢復了正常。
下午,我們我們調整了伺服器的部署,用了更多伺服器進行混合部署(docker-compose與docker swarm),情況有了明顯改善。
但是,15:15 開始資料庫 CPU 又飈了上去,但訪問速度沒有受到明顯影響,一致堅持到 16:50 左右,在扛不住的時候,我們再次通過主備切換恢復了正常。
這次恢復正常後,我們才突然想到,資料庫每天一大早會跑一個整理索引碎片的任務,是不是升級後這個任務不能正常執行了?開啟 SSMS 一看,果然是。
昨天因為升級 SQL Server 後重建備庫,整理索引碎片任務失敗了。
Date 9/5/2019 06:30:00 Log Job History (Reorganize Index) Step ID 1 Server SD39184A Job Name Reorganize Index Step Name Reorganize Index Duration 00:00:00 Sql Severity 14 Sql Message ID 927 Message Executed as user: xxx. Database 'xxx' cannot be opened. It is in the middle of a restore. [SQLSTATE 42000] (Error 927). The step failed.
今天不知什麼原因整理索引碎片的任務也失敗了。
Date 9/6/2019 06:30:00 Log Job History (Reorganize Index) Step ID 1 Server SD39184A Job Name Reorganize Index Step Name Reorganize Index Duration 00:00:00 Sql Severity 14 Sql Message ID 954 Message Executed as user: xxx. The database "xxx" cannot be opened. It is acting as a mirror database. [SQLSTATE 42000] (Error 954). The step failed.
CPU 高的問題很可能就是索引碎片沒有被及時整理引起的,是否真的是這個原因,要等下週的訪問高峰才能得到驗證。
對於升級後整理索引碎片任務失敗的問題,我們向阿里雲提交工單後,阿里雲建議我們先關閉 mirror database 。
alter database 庫名 set partner off
目前我們沒有采用這個建議,還在考慮更好的解決方法。