mongo 複製的分片成員無法恢復，卡在 STARTUP2 模式

我對 Amazon VPC 中的分片副本集進行了以下設置：

mongo1: 8G RAM Duo core (Primary)

mongo2: 8G RAM Duo core (Secondary)

mongo3：4G RAM（仲裁器）

mongo1 是副本集中的主要成員，具有 2 個分片設置：

mongod --port 27000 --dbpath /mongo/config -- configsvr 

mongod --port 27001 --dbpath /mongo/shard1 --shardsvr --replSet rssh1

mongod --port 27002 --dbpath /mongo/shard2 --shardsvr --replSet rssh2

Mongo2 是副本集中的次要成員，完全反映了 mongo1：

mongod --port 27000 --dbpath /mongo/config -- configsvr 

mongod --port 27001 --dbpath /mongo/shard1 --shardsvr --replSet rssh1   # Faulty process

mongod --port 27002 --dbpath /mongo/shard2 --shardsvr --replSet rssh2

然後由於某種原因，上週mongo2上的27001程序由於記憶體不足（原因未知）發生了崩潰。當我發現這個問題（應用程序仍然可以從主伺服器獲取數據）並重新啟動 27001 程序時，在 mongo1 上趕上 shard1 為時已晚。所以我遵循了 10gen 的建議：

• 清空目錄 /mongo/shard1
• 使用命令重啟27001程序

mongod --port 27001 --dbpath /mongo/shard1 --shardsvr --replSet rssh1

但是現在已經超過 24 小時，節點仍處於STARTUP2模式，我有大約 200G 的數據，shard1看起來它/mongo/shard1在 mongo2 上得到了大約 160G。以下是副本集狀態命令輸出（執行在mongo2）

rssh1:STARTUP2> rs.status()
{
    "set" : "rssh1",
    "date" : ISODate("2012-10-29T19:28:49Z"),
    "myState" : 5,
    "syncingTo" : "mongo1:27001",
    "members" : [
         {
              "_id" : 1,
              "name" : "mongo1:27001",
              "health" : 1,
              "state" : 1,
              "stateStr" : "PRIMARY",
              "uptime" : 99508,
              "optime" : Timestamp(1351538896000, 3),
              "optimeDate" : ISODate("2012-10-29T19:28:16Z"),
              "lastHeartbeat" : ISODate("2012-10-29T19:28:48Z"),
              "pingMs" : 0
         },
         {
              "_id" : 2,
              "name" : "mongo2:27001",
              "health" : 1,
              "state" : 5,
              "stateStr" : "STARTUP2",
              "uptime" : 99598,
              "optime" : Timestamp(1351442134000, 1),
              "optimeDate" : ISODate("2012-10-28T16:35:34Z"),
              "self" : true
         },
         {
              "_id" : 3,  
              "name" : "mongoa:27901",
              "health" : 1,
              "state" : 7,
              "stateStr" : "ARBITER",
              "uptime" : 99508,
              "lastHeartbeat" : ISODate("2012-10-29T19:28:48Z"),
              "pingMs" : 0
         }
    ],
    "ok" : 1
}

rssh1:STARTUP2> 

看起來大部分來自主數據庫的數據都被複製了，但不是全部。日誌顯示一些錯誤，但我不知道它是否相關：

10 月 29 日星期一 19:39:59 [TTLMonitor] 斷言 13436 不是主控或輔助；目前無法從此 replSet 成員讀取 ns:config.system.indexes 查詢：{ expireAfterSeconds: { $exists: true } }

10 月 29 日星期一 19:39:59 [TTLMonitor] 在查詢 config.system.indexes 期間檢測到問題：{ $err：“不是主設備或輔助設備；目前無法從此 replSet 成員讀取”，程式碼：13436 }

10 月 29 日星期一 19:39:59 [TTLMonitor] 錯誤：為 db 處理 ttl 時出錯：配置 10065 無效參數：預期對象（）

10 月 29 日星期一 19:39:59 [TTLMonitor] 斷言 13436 不是主控或輔助；目前無法從此 replSet 成員讀取 ns:gf2.system.indexes 查詢：{ expireAfterSeconds: { $exists: true } }

10 月 29 日星期一 19:39:59 [TTLMonitor] 在查詢 gf2.system.indexes 期間檢測到問題：{ $err：“不是主設備或輔助設備；目前無法從此 replSet 成員讀取”，程式碼：13436 }

10 月 29 日星期一 19:39:59 [TTLMonitor] 錯誤：db 處理 ttl 時出錯：gf2 10065 無效參數：預期對象（）

10 月 29 日星期一 19:39:59 [TTLMonitor] 斷言 13436 不是主控或輔助；目前無法從此 replSet 成員讀取 ns:kombu_default.system.indexes 查詢：{ expireAfterSeconds: { $exists: true } }

10 月 29 日星期一 19:39:59 [TTLMonitor] 在查詢 kombu_default.system.indexes 期間檢測到問題：{ $err: "not master or secondary;目前無法從此 replSet 成員讀取"，程式碼：13436 }

10 月 29 日星期一 19:39:59 [TTLMonitor] 錯誤：db 處理 ttl 時出錯：kombu_default 10065 無效參數：預期對象（）

小學的一切似乎都很好。日誌中沒有錯誤。

我嘗試了兩次這些步驟，一次執行 mongo 配置伺服器，一次執行 mongo 配置伺服器，兩者結果相同。

這是一個生產設置，我真的需要讓副本集恢復工作，非常感謝任何幫助。

如果沒有完整的日誌，這將很難診斷，但讓輔助伺服器恢復正常的最簡單方法是從主伺服器從頭開始重新同步它。基本上停止那個mongod，刪除dbpath（包括子目錄）中的所有數據，然後重新啟動。它將像新成員一樣啟動同步過程。

對於它的價值，在聽起來像 m1.large 的實例上執行兩個完整的實例（主/次）可能會看到很多資源爭用，尤其是在磁碟方面。

就墜機而言，根據有限的證據，它可能是 OOM 殺手在起作用：

http://www.mongodb.org/display/DOCS/The+Linux+Out+of+Memory+OOM+Killer

為避免這種情況，請確保配置了一些交換空間。

如果你在 mongo2 上執行

db.printSlaveReplicationInfo()

你看到了什麼 ？

您還可以做的是從副本集中刪除 mongo2 - 從 mongo2 中刪除所有數據並重新添加它。

rs.remove("mongo2:27001")
rs.add("mongo2:27001")
rs.status()

引用自：https://dba.stackexchange.com/questions/27918