RS102 MongoDB on ReplicaSet

Question

我已經設置了一個包含4個服務器的副本集。

爲了測試目的，我使用GridFS編寫了一個腳本來填充我的數據庫至約150百萬行照片。我的照片大約在15KB左右。 （？！這不應該是使用GridFS的對小文件有問題）

後數小時後，有大約5000萬行，但我在日誌此消息：

replSet error RS102 too stale to catch up, at least from 192.168.0.1:27017 

這裏是複製集狀態：

rs.status(); 
{ 
"set" : "rsdb", 
"date" : ISODate("2012-07-18T09:00:48Z"), 
"myState" : 1, 
"members" : [ 
    { 
     "_id" : 0, 
     "name" : "192.168.0.1:27017", 
     "health" : 1, 
     "state" : 1, 
     "stateStr" : "PRIMARY", 
     "optime" : { 
      "t" : 1342601552000, 
      "i" : 245 
     }, 
     "optimeDate" : ISODate("2012-07-18T08:52:32Z"), 
     "self" : true 
    }, 
    { 
     "_id" : 1, 
     "name" : "192.168.0.2:27018", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64770, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 2, 
     "name" : "192.168.0.3:27019", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 64735, 
     "optime" : { 
      "t" : 1342539026000, 
      "i" : 5188 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:30:26Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:47Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    }, 
    { 
     "_id" : 3, 
     "name" : "192.168.0.4:27020", 
     "health" : 1, 
     "state" : 3, 
     "stateStr" : "RECOVERING", 
     "uptime" : 65075, 
     "optime" : { 
      "t" : 1342539085000, 
      "i" : 3838 
     }, 
     "optimeDate" : ISODate("2012-07-17T15:31:25Z"), 
     "lastHeartbeat" : ISODate("2012-07-18T09:00:46Z"), 
     "pingMs" : 0, 
     "errmsg" : "error RS102 too stale to catch up" 
    } 
], 
"ok" : 1 

設定仍然接受DATAS，但我有我的3個服務器「DOWN」我應該如何着手修理（更好不是刪除DATAS和重新同步WH呃會過時，但會起作用）？

特別是： 這是因爲太劇烈的腳本？這意味着它在生產中幾乎從未發生過？

Answer 1

您不需要修復，只需執行完整的重新同步。

在次級，您可以：

1. 停止失敗的mongod
2. 刪除DBPATH（包括子目錄）
3. 重啓的所有數據，它會自動重新同步自身

按照說明here。

你的情況發生了什麼事情，你的輔助變得陳舊了，即他們的oplog和主要oplog沒有共同點。看看這個document，它詳細介紹了各種狀態。對主要成員的寫入必須被複制到輔助節點，並且你的輔助節點不能跟上，直到它們最終失效。你需要考慮調整你的oplog。

關於oplog大小，取決於您插入/更新的數據量。我會選擇一個大小，允許你幾個小時甚至幾天的oplog。

此外，我不確定您正在運行哪個操作系統。但是，對於64位Linux，Solaris和FreeBSD系統，MongoDB會將5％的可用磁盤空間分配給oplog。如果這個數量小於千兆字節，那麼MongoDB將分配1千兆字節的空間。對於64位OS X系統，MongoDB爲oplog和32位系統分配183兆字節的空間，MongoDB爲oplog分配大約48兆字節的空間。

記錄有多大，你想要多少？這取決於數據插入是否是典型的或者僅僅是測試的異常。

例如，對於1KB的文檔，每秒處理2000個文檔，這會使您每分鐘處理120MB，並且您的5GB oplog將持續大約40分鐘。這意味着，如果次要服務器在40分鐘內脫機或落後多於此時間，則表明您已經陳舊，必須進行完全重新同步。

我推薦閱讀Replica Set Internals文件here。您的副本集中有4個成員，這是不推薦的。您應該爲voting election (of primary) process設置一個奇數，所以您需要添加一個仲裁器，另一個輔助器或刪除其中一個輔助器。

最後，這裏是關於RS administration的詳細文檔。