一個mongodb索引BUG引起的血案

簡述

2020.01.21 2：00

作了一個索引優化。將3個索引優化爲1個。只保留了一個{session_id, create_timestamp}索引，更到線上後未發現大的問題。

2020.01.24 1：00

發現數據庫訪問RTT不明緣由地升高。觸發了限流，部分用戶不能登陸。由於凌晨的訪問量是平時的3-5倍。由於各方面指標都慢慢趨於正常。未作更多處理。

2020.01.24 16：00

午睡時想到凌晨的種種奇怪現象（另外一個database的RTT也變高了）。
徹底不相干的兩個database。CPU沒遇到瓶頸，只多是磁盤IO了。一看磁盤IO嚇一跳，竟然是滿的！（訝異於沒有磁盤IO報警，也訝異於索引有不對的地方），mongotop一看。相關table的read/write 都在1Kms級別。
仔細地比較各個操做的rtt時間，發現msg表的update從更新前的1ms內，上漲到了6-7ms。msg表最慢的round trip，沒有大的變化。看來是長尾效應致使的問題。
查看代碼時發現，在設置消息已讀時，正常狀況下會在unread_sessions拿到該會話的一個未讀create_timestamp，在設置後，會清理掉該create_timestamp。在設置一個無unread的會話時，拿不到時間戳，會向前檢索一週的消息。從慢查詢日誌中發現，有update操做會遍歷300多條記錄。
以後的fix和更新就不談了。

總結

任何線上問題的發生都是多個錯誤綜合形成的。總結以下:

監控

• 磁盤IO報警沒有生效。
• 應用層監控缺少數據庫的總體表現狀況。除了關注最壞rtt, 特定接口的rtt，還要關注總體狀況。最直觀的就是mongotop，磁盤IO使用率，CPU使用率，網絡IO使用率。
• 應監控慢查詢的數量，達到必定閾值報警。

灰度

測試機器人和用戶表現不一致。須要灰度機制發現問題。

敬畏心

作服務端要細心，動的時候就有點慫。動完應對線上狀況作更多觀測（當時以爲有任意索引BUG，都會致使整個數據庫卡死，10億規模的表）。