MongoDB做了replica sets之后,secondary節點出現recovering狀態
在一次mongo集群掛掉后，重啟，發現有一臺服務器的mongo節點一直處于recovering狀態，不能變為secondary或者primary。
查詢官方文檔后，找到解決方案，在此記錄。
出現原因
備份節點的工作原理過程可以大致描述為，備份節點定期輪詢主節點上的數據操作，然后對自己的數據副本進行這些操作，從而保證跟主節點的數據同步。
至于主節點上的所有數據庫狀態改變的操作，都會存放在一張特定的系統表中。備份節點則是根據這些數據進行自己的數據更新。
上面提到的數據庫狀態改變的操作，稱為oplog（operation log，主節點操作記錄）。oplog存儲在local數據庫的"oplog.rs"表中。副本集中備份節點異步的從主節點同步oplog，然后重新執行它記錄的操作，以此達到了數據同步的作用。
關于oplog有幾個注意的地方：
- oplog只記錄改變數據庫狀態的操作
- 存儲在oplog中的操作并不是和主節點執行的操作完全一樣，例如"$inc"操作就會轉化為"$set"操作
- oplog存儲在固定集合中(capped collection)，當oplog的數量超過oplogSize，新的操作就會覆蓋舊的操作
數據同步
在副本集中，有兩種數據同步方式：
- initial sync（初始化）：這個過程發生在當副本集中創建一個新的數據庫或其中某個節點剛從宕機中恢復，或者向副本集中添加新的成員的時候，默認的，副本集中的節點會從離它最近的節點復制oplog來同步數據，這個最近的節點可以是primary也可以是擁有最新oplog副本的secondary節點。
- 該操作一般會重新初始化備份節點，開銷較大
- replication（復制）：在初始化后這個操作會一直持續的進行著,以保持各個secondary節點之間的數據同步。
initial sync
當遇到上面例子中無法同步的問題時，只能使用以下兩種方式進行initial sync了
- 第一種方式就是停止該節點，然后刪除目錄中的文件，重新啟動該節點。這樣，這個節點就會執行initial sync
注意：通過這種方式，sync的時間是根據數據量大小的，如果數據量過大，sync時間就會很長
同時會有很多網絡傳輸，可能會影響其他節點的工作 - 第二種方式，停止該節點，然后刪除目錄中的文件，找一個比較新的節點，然后把該節點目錄中的文件拷貝到要sync的節點目錄中
