怎麼設定資料庫的報警

xuexiaogang發表於2022-07-19

  報警分為幾種(結合我各行各業的工作經驗):

1、無報警(這裡主要說是資料庫已經不行了,但是報警沒有提示。因為設定90%報警,且要持續5分鐘,現在是80%,持續了幾個小時。)

2、使用者操作出現問題(同時我們系統也發現問題)和使用者同時發現。比如使用者點選頁面1秒 2秒 3秒 。。。10秒沒出,報502 503等50X 等等.  這個時候我們後臺也會報警。這種要先於使用者不現實。他沒操作之前,這個不知道他點下去是不是超時。

3、在使用者操作之後,比如報警提示,鎖持續1分鐘(3分鐘、5分鐘),估計投訴電話都打過來了。

4、還有一種是監控比較難以察覺的,比如主從資料庫同步有延遲,或者異構資料庫透過CDC同步有延遲。其實延遲不是說一旦延遲就是問題,但是延遲大了一定是問題。這個尺度不好拿捏。比如延遲10秒,可能沒事,但是恰好有個系統居然那一個時刻就不能延遲。

5、關係型資料庫到NoSQL或者到訊息佇列的不一致性(我覺得天生這種就不可能保障一致性,基本無解)

以上個人水平有限列了一些主要的,一定有其他的。我們先討論這些主要的。

      針對問題1:其實資料庫的CPU超過50%的使用率,就開始出現有些請求等待了。有一次在一個技術大會上Oracle的RWP給我們演示了一次壓力測試。所以這也是我對各種資料庫上的要求,不能是常規的報警界限。

      針對問題2:這種可能我們不能100%避免,但是能做的是在上線前,SQL稽核以及壓測。如果我們的主流程或者說高頻訪問的SQL,都控制在50ms、20ms甚至幾毫秒、微秒級別。那麼是可以預防的。一切皆有可能。有一次我就是把一個SQL從20分鐘最佳化到了不到2毫秒。(你要問怎麼做到的,報名上我的課吧)

      針對問題3:設計上避免長事務鎖甚至設計不要鎖的場景。比如update 業務單一ID,基本不會鎖(除非故意不提交),還有拍賣設計成insert出價,而不是update價格。

      針對問題4:禁止大事務。任何CDC都怕大事務。別說CDC怕了,就是主從資料庫也怕。我經歷過多次這樣導致資料庫主從斷了的情況。不怪資料庫。話說能不能CDC(資料同步)就不用。

      針對問題5:好好設計表,好好寫SQL。減少資料庫數量和異構資料庫以及中介軟體。(當真正經歷過就會發現,單套資料庫的開發和運維真的是最幸福的事情了)

      總結一下,會發現好好寫SQL,解決了以上所有問題。然後你的資料庫真的基本就沒有報警了。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/637517/viewspace-2906417/,如需轉載,請註明出處,否則將追究法律責任。

相關文章