爲什麼我的MongoDB副本繼續落後？

Question

昨晚將收藏集轉換爲封面收藏集時，我的輔助時間開始落後於小學。它每隔幾分鐘就會緩慢地前進幾秒鐘，最終從主要的oplog窗口中退出。根據指令here，我停止了輔助節點上的mongod，刪除了所有數據文件，並重新啓動了它，但我忘記鎖定主節點。中學經歷了其初始階段，這需要花費很長時間，並且終於恢復了業務，但是當我登錄時，複製現在更加落後了。

因爲這是雲，畢竟我創建了一個我的主映像（它應該複製所有數據）的映像，儘管我當時無法運行db.fsyncLock（），因爲它需要一些寫道。新圖像完成後，我會啓動一個基於該圖像的新服務器，將它添加到我的副本集，刪除舊的輔助圖像，並且生活很好，對不對？不完全 - 新的中學落後了大約一個小時，並且在一天中（和今天晚上）最終達到落後14個小時的時間（儘管仍然在oplog窗口內仍然奇怪）。

我從「重新陳舊的成員頁面」開始下一步。在兩臺服務器上關閉mongod，gzip並將我的數據文件夾從主要副本複製到輔助副本，然後解壓並將它們同時激活，db.fsyncLock（）是我的主要副本。我的想法是，即使在初始化完成之後，我的輔助者說，它已經落後了1個小時。我將它重新添加到副本集中，並迅速趕上5分鐘後。

所有不錯，對不對？沒有 - 向前閃，中學正在前進，現在落後20分鐘。 Mongostat有95％以上的鎖定率，iostat -xm 2沒有顯示任何瘋狂的情況 - 小學目前由於沒有寫入而處於閒置狀態，二級絕對沒有太多的工作（0.04 WMB /秒）。不知道是否值得一提，但目前初級感覺 狗慢 登錄進mongo shell等反應遲鈍

什麼給Mongo？爲什麼你不能趕上？我試圖讓自己的第二手被抓住，我做錯了什麼？

編輯 回答問題：

• 版本：2.0.4
• 硬件：兩個節點在相同的硬件，靠近我可以告訴大家 - 8GB的內存，四核CPU。我認爲這是虛擬化的東西。
• 寫入速率：不同。如前所述，昨天晚上我轉變爲封頂收藏，這引發了整個事情。一夜之間，有一個過程每小時幾次寫幾百個小文檔（每個大約155字節），所以我估計大約100-200kbytes /小時。在白天，處理更加激烈，更新了數十萬個500字節的文檔，並且編寫了幾十萬個文檔。仍然沒有談論巨大的數據量。 EDIT發現從今天早些時候一些iostat的輸出：

 
Device:   rrqm/s wrqm/s  r/s  w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util 
xvda    1.00 2564.50 243.50 282.50 8986.00 11388.00 77.47 11.32 21.46 2.36 37.93 0.50 26.50 

那一個是在11 WMB/s的特別突發，鋸UTIL％擊中34％與7 WMB/s，並且在52元72％/秒。所以不是飽和的，但肯定是早上的閱讀繁重的工作量。儘管有obj，但它很有趣。大小〜5GB，以及〜1GB的索引（見下文），磁盤活動非常多。不應該全部在RAM中嗎？

• 工作集：我還沒有找到計算工作組接受的方法，但如果它可以幫助：

 
    "collections" : 21, 
    "objects" : 15540092, 
    "avgObjSize" : 325.26198326238995, 
    "dataSize" : 5054601144, 
    "storageSize" : 5874327552, 
    "numExtents" : 132, 
    "indexes" : 43, 
    "indexSize" : 864366720, 
    "fileSize" : 10666115072, 
    "nsSizeMB" : 16, 
    "ok" : 1 

我無法想象，這是的RAM 8GB鋪天蓋地，但我可能是錯的。

• 從二級最近的一些mongostat樣本：

 
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss %  qr|qw ar|aw netIn netOut conn set repl  time 
    *0  *0  *0  *0  0  1|0  0 22.2g 44.9g 912m  0  99.2   0  0|0  0|1  2k 303b 151 mySet SEC 03:47:54 
    *0  *0  *0  *0  0  1|0  0 22.2g 44.9g 1.85g  0  101   0  0|0  0|1  3k 303b 151 mySet SEC 03:48:04 

編輯

嘗試更多的東西。我關閉了主服務器（現在叫做A，次要服務器會是B），刪除了它的數據，並且解壓了它的快照（現在已經過了幾個小時了，但是現在我們並沒有寫任何新的東西）。開始使用--fastsync，它仍然比B（現在主要）的optime晚了45秒，這個時間大約在02：19：52UTC。最後大約一個小時後，A趕上了，所以我在B上調用了rs.stepDown（）。即時地，rs.status（）告訴我兩臺服務器在UTC時間04:08左右都有optimes，但是B（現在是次要的）再次滯後17數秒然後在30秒......現在7分鐘...

編輯

採取@ matulef的建議，並幾分鐘後重新創建我的收藏上限指標，以及重新啓動輔助的mongod進程，其運行時間只增加了幾秒鐘。來自mongostat的二級鎖定百分比仍然在95-104％之間徘徊，有趣的是，res size的大小從100M到2GB變得非常大，然後又回到了1GB左右。

EDIT（第二天晚上）

結論的故事 - @matulef是在正確的軌道上，我應該更小心複製的集合轉換爲上限的集合。接下來是發生了什麼，雖然我沒有宣傳這是數據安全的 - 我自由地承認我可能在這個過程中丟失了一些數據，所以YMMV。

在主（A）上創建加蓋集合的索引不會傳播到輔助節點（B），並且偶然發生故障切換（並非有意）。一旦B是主要的，我手動在那裏的封頂集合上創建索引，並且使A與B一致的再同步操作開始快速移動。不幸的是，我的oplog窗口不再排隊，所以我最終不得不將數據從B快照到A.一旦我用相同的數據重新啓動了mongo，A & B又開心了，複製又回來了從此同步。

Answer 1

這裏的問題是，默認情況下，加蓋集合沒有_id索引（並且「convertToCapped」命令實際上會爲該集合刪除全部索引）。這是一個問題，因爲輔助人員通過應用來自oplog的ops來執行更新，opks通過_ids引用文檔。如果缺少_id索引，則每個更新都需要對輔助節點進行全表掃描，導致它們遠遠落後。

解決方法是在封頂集合上創建一個_id索引。但是，如果您在主服務器上創建索引，但您的副服務器已經落後，他們將不會足夠快地接收索引創建操作。相反，解決問題的最佳方法是首先逐個修正每個滯後的次要問題。對於每一個，關閉它並以獨立模式重新啓動（在不同的端口上，不帶--replSet選項），構建_id索引，然後將其添加回集中。最後，一旦輔助人員解決了問題，您可以降低主要人員，並重復此過程。

更新：在mongoDB 2.0.x和更早的版本中，默認情況下，capped集合沒有_id索引。但是，默認行爲計劃在mongoDB 2.2中更改，以便在2.2+中創建的加蓋集合將自動創建_id索引，就像非封頂集合一樣。對於2.2之前創建的封頂集合，您仍然需要使用上述步驟手動創建_id索引，但新集合不應該遭受上述問題。