MongoDB建索引時(shí)是否無法登錄應(yīng)用

MongoDB建索引時(shí)是否無法登錄應(yīng)用，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

背景介紹：

    Mongodb版本 3.0.2

    建索引和collection和賬號(hào)查詢collection所在同一臺(tái)服務(wù)器，不同庫名上。

    因使用的是mongodb3.0.2，之前了解到3.0是行級(jí)鎖，于是dba在建該表索引時(shí)，并未加參數(shù)background:true。

查原因：

    同事無法登錄應(yīng)用的時(shí)間點(diǎn)恰巧是該庫有建索引的時(shí)間段。于是主要排查在索引上。后來通過復(fù)現(xiàn)問題，確認(rèn)了該問題。

當(dāng)主庫開始建索引時(shí)，主庫的讀寫是正常的。應(yīng)用可以正常訪問。但當(dāng)主庫索引建立完成，Secondary 拉取到一批 oplog 后，從庫開始重放oplog時(shí)，此時(shí)就有一個(gè)特殊 Lock::ParallelBatchWriterMode 的鎖，這個(gè)鎖會(huì)阻塞所有的讀請(qǐng)求。 這就解釋了為什么在建索引之后的 幾分鐘，應(yīng)用無法訪問。

后查閱了資料：

• 盡量避免臟讀，等一批 oplog 重放完后，這批數(shù)據(jù)才允許用戶讀到。

• 盡量保證同步性能，設(shè)想一下，如果重放 oplog 時(shí)，使用普通的鎖，那么 oplog 的重放就需要跟正常的讀寫競爭鎖資源，如果 Secondary 上有大量的讀，那么勢必會(huì)造成備同步逐步跟不上。

  
  

雖然3.0版本的讀寫鎖沒有對(duì)數(shù)據(jù)庫造成阻塞，但不要忽略同步鎖 Lock::ParallelBatchWriterMode的影響。

解決問題：

在數(shù)據(jù)庫盡量空閑的狀態(tài)下建索引；

在建索引時(shí)，最好還是加上 background:true。

關(guān)于MongoDB建索引時(shí)是否無法登錄應(yīng)用問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。