MongoDB Secondary 延時高（同步鎖）案例分析

遇到問題：晚10點，DBA在數據庫創建了某collection的索引。在以後的幾分鐘，恰巧有同事訪問某應用，驗證該應用的帳號需從數據庫某表查詢帳號密碼。致使了沒法查詢，同事沒法登陸上應用。問題便反饋到了運維部。

背景介紹：

    Mongodb版本 3.0.2

    建索引和collection和帳號查詢collection所在同一臺服務器，不一樣庫名上。

    因使用的是mongodb3.0.2，以前瞭解到3.0是行級鎖，因而dba在建該表索引時，並未加參數background:true。

查緣由：

    同事沒法登陸應用的時間點恰巧是該庫有建索引的時間段。因而主要排查在索引上。後來經過復現問題，確認了該問題。

當主庫開始建索引時，主庫的讀寫是正常的。應用能夠正常訪問。但當主庫索引創建完成，Secondary 拉取到一批 oplog 後，從庫開始重放oplog時，此時就有一個特殊 Lock::ParallelBatchWriterMode 的鎖，這個鎖會阻塞全部的讀請求。 這就解釋了爲何在建索引以後的 幾分鐘，應用沒法訪問。

後查閱了資料：

• 儘可能避免髒讀，等一批 oplog 重放完後，這批數據才容許用戶讀到。

• 儘可能保證同步性能，設想一下，若是重放 oplog 時，使用普通的鎖，那麼 oplog 的重放就須要跟正常的讀寫競爭鎖資源，若是 Secondary 上有大量的讀，那麼勢必會形成備同步逐步跟不上。

雖然3.0版本的讀寫鎖沒有對數據庫形成阻塞，但不要忽略同步鎖 Lock::ParallelBatchWriterMode的影響。

解決問題：

在數據庫儘可能空閒的狀態下建索引；

在建索引時，最好仍是加上 background:true。