之前有遇到過MongoDB Replica Set中的某個Secondary節點一直持續Recovering狀態，無法恢復，且上次操作時間（optimeDate）已經是N天前了，經過查看官方文檔，得知出現這種情況的原因在于復制集中主節點（Primary）一直寫入oplog，而從節點（Secondary）的復制過程遠遠落后，趕不上主節點的oplog寫入，就像賭氣的孩子跑步一樣，趕不上前面的小伙伴，索性一賭氣就不走了……當遇到這種情況的時候，是不可能指望從節點自己恢復的，需要我們手動重新同步（initial sync）。

官方給出了兩種執行重新同步的方式——

• 完全清空數據目錄然后重啟mongod服務
• 在其他成員的數據目錄下拷貝最近的數據然后重啟mongod服務

這里，偷懶不想打包scp數據，索性采用了第一種方式：

1. 停止mongod服務：可在mongo shell中執行db.shutdownServer()來關閉mongod服務，也可以在shell中直接敲mongod --shutdown，或者簡單粗暴直接kill -2 <PID>（這里不推薦-9，會造成下次啟動不起來的情況，需要刪除dbPath目錄下的mongo.lock再嘗試重新啟動）。
2. 對舊的dbPath的目錄重命名，以做備份
3. 啟動mongod，指向新的空的dbPath目錄

簡單三步，MongoDB就會重新進行初始化同步，受限于數據量和網絡環境等因素的影響，重新同步時間有長有短。重新同步完畢后，打開mongo shell查看復制集狀態，一般情況下，這個從節點狀態就會恢復正常了。然后要做的就是驗證主從數據一致性，確保沒問題之后，重命名過的dbPath目錄可以刪除了。

第二種方式，利用其它成員的最近數據進行啟動的操作可見官方文檔，這里就不贅述了。