MongoDB的輔助程序沒有趕上

我有一個副本集，我試圖升級主內存到更多的內存和升級的磁盤空間。因此，我在新的主服務器上搜索了幾個磁盤，並從輔助服務器rsync了數據並將其添加到副本集。檢查完rs.status（）之後，我注意到所有輔助節點都在主節點後面約12小時。所以當我試圖強制新服務器到主要位置時，它將不起作用，因爲它不是最新的。MongoDB的輔助程序沒有趕上

這似乎是一個大問題，因爲如果主要失敗，我們至少需要12個小時，並且有一些將近48個小時。

oplogs全部重疊，oplogsize相當大。我唯一能想到的是我在主服務器上執行了大量的寫入/讀取操作，這可能會使服務器處於鎖定狀態，無法正常工作。

有沒有辦法可能迫使一個輔助追趕主要？

目前有5個服務器最後2個替換2個其他節點。 _id爲6的節點將成爲替換主節點的節點。離主要運行時間最遠的節點超過了48小時。

{ 
"set" : "gryffindor", 
"date" : ISODate("2011-05-12T19:34:57Z"), 
"myState" : 2, 
"members" : [ 
    { 
     "_id" : 1, 
     "name" : "10******:27018", 
     "health" : 1, 
     "state" : 2, 
     "stateStr" : "SECONDARY", 
     "uptime" : 20231, 
     "optime" : { 
      "t" : 1305057514000, 
      "i" : 31 
     }, 
     "optimeDate" : ISODate("2011-05-10T19:58:34Z"), 
     "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z") 
    }, 
    { 
     "_id" : 2, 
     "name" : "10******:27018", 
     "health" : 1, 
     "state" : 2, 
     "stateStr" : "SECONDARY", 
     "uptime" : 20231, 
     "optime" : { 
      "t" : 1305056009000, 
      "i" : 400 
     }, 
     "optimeDate" : ISODate("2011-05-10T19:33:29Z"), 
     "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z") 
    }, 
    { 
     "_id" : 3, 
     "name" : "10******:27018", 
     "health" : 1, 
     "state" : 1, 
     "stateStr" : "PRIMARY", 
     "uptime" : 20229, 
     "optime" : { 
      "t" : 1305228858000, 
      "i" : 422 
     }, 
     "optimeDate" : ISODate("2011-05-12T19:34:18Z"), 
     "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z") 
    }, 
    { 
     "_id" : 5, 
     "name" : "10*******:27018", 
     "health" : 1, 
     "state" : 2, 
     "stateStr" : "SECONDARY", 
     "uptime" : 20231, 
     "optime" : { 
      "t" : 1305058009000, 
      "i" : 226 
     }, 
     "optimeDate" : ISODate("2011-05-10T20:06:49Z"), 
     "lastHeartbeat" : ISODate("2011-05-12T19:34:56Z") 
    }, 
    { 
     "_id" : 6, 
     "name" : "10*******:27018", 
     "health" : 1, 
     "state" : 2, 
     "stateStr" : "SECONDARY", 
     "optime" : { 
      "t" : 1305050495000, 
      "i" : 384 
     }, 
     "optimeDate" : ISODate("2011-05-10T18:01:35Z"), 
     "self" : true 
    } 
], 
"ok" : 1 
}

來源

2011-05-12 Bryan

你可以發佈rs.status（）的輸出作爲從其中一個副本運行嗎？ – 2011-05-12 14:45:23

我想如果你在StackOverflow的姊妹網站ServerFault.com上提出這個問題，你會得到更好的答案 – Theo 2011-05-12 19:42:09

謝謝，我只是這麼做的。 http://serverfault.com/questions/269184/mongodb-secondaries-not-catching-up – Bryan 2011-05-12 19:49:42

查看完所有內容後，我看到一個錯誤，這導致我回到在主節點上運行的mapreduce，該節點出現此問題：https://jira.mongodb.org/browse/SERVER-2861。因此，當嘗試複製時，由於oplog中的錯誤/損壞操作而無法同步。

來源

2011-05-13 16:21:13 Bryan

這個bug幾年前就已經修復了。你確定你運行的是舊版本嗎？ – 2014-05-19 19:35:12

這是大約2011年，當時1.8.0是我們運行的版本。正如您在JIRA問題中看到的那樣，它在2011年3月進行了修補。僅在這個問題提前幾個月纔回答。 – Bryan 2014-05-20 19:48:40

對不起，我沒有意識到這是多大年紀。 SO最近的問題列出了它。 – 2014-05-21 02:14:59

我不知道爲什麼同步你的情況已經失敗，但蠻力重新同步的一種方法是刪除副本服務器上的數據文件，然後重新啓動mongod的。它將啓動重新同步。請參閱http://www.mongodb.org/display/DOCS/Halted+Replication。這可能需要相當長的時間，取決於數據庫的大小。

來源

2011-05-12 14:21:45

resync在副本集上確實無效。同樣，刪除數據文件並重新啓動也不是最好的選擇，因爲它需要數天才能恢復。這也不能解決問題，因爲我有一個同樣規格的服務器，我離開它自己恢復，它和其他二級服務器一樣「老」。 – Bryan 2011-05-12 14:33:53

@Bryan：是的，剛剛嘗試了resync命令，並意識到我的失敗。回答編輯。由於您已經允許副本完全重新同步，並且它也是陳舊的，我不確定問題是什麼。我會想一想。 – 2011-05-12 14:38:10

MongoDB的輔助程序沒有趕上

回答

相關問題