MongoDB做了replica sets之后,secondary節(jié)點出現(xiàn)recovering狀態(tài)
在一次mongo集群掛掉后，重啟碎连，發(fā)現(xiàn)有一臺服務(wù)器的mongo節(jié)點一直處于recovering狀態(tài)灰羽，不能變?yōu)閟econdary或者primary。
查詢官方文檔后鱼辙，找到解決方案廉嚼，在此記錄。
出現(xiàn)原因
備份節(jié)點的工作原理過程可以大致描述為倒戏，備份節(jié)點定期輪詢主節(jié)點上的數(shù)據(jù)操作怠噪，然后對自己的數(shù)據(jù)副本進行這些操作，從而保證跟主節(jié)點的數(shù)據(jù)同步杜跷。
至于主節(jié)點上的所有數(shù)據(jù)庫狀態(tài)改變的操作傍念，都會存放在一張?zhí)囟ǖ南到y(tǒng)表中。備份節(jié)點則是根據(jù)這些數(shù)據(jù)進行自己的數(shù)據(jù)更新葛闷。
上面提到的數(shù)據(jù)庫狀態(tài)改變的操作憋槐，稱為oplog（operation log，主節(jié)點操作記錄）淑趾。oplog存儲在local數(shù)據(jù)庫的"oplog.rs"表中阳仔。副本集中備份節(jié)點異步的從主節(jié)點同步oplog，然后重新執(zhí)行它記錄的操作治笨，以此達到了數(shù)據(jù)同步的作用驳概。
關(guān)于oplog有幾個注意的地方：
- oplog只記錄改變數(shù)據(jù)庫狀態(tài)的操作
- 存儲在oplog中的操作并不是和主節(jié)點執(zhí)行的操作完全一樣，例如"$inc"操作就會轉(zhuǎn)化為"$set"操作
- oplog存儲在固定集合中(capped collection)旷赖，當oplog的數(shù)量超過oplogSize顺又，新的操作就會覆蓋舊的操作
數(shù)據(jù)同步
在副本集中，有兩種數(shù)據(jù)同步方式：
- initial sync（初始化）：這個過程發(fā)生在當副本集中創(chuàng)建一個新的數(shù)據(jù)庫或其中某個節(jié)點剛從宕機中恢復(fù)等孵，或者向副本集中添加新的成員的時候稚照，默認的，副本集中的節(jié)點會從離它最近的節(jié)點復(fù)制oplog來同步數(shù)據(jù)俯萌，這個最近的節(jié)點可以是primary也可以是擁有最新oplog副本的secondary節(jié)點果录。
- 該操作一般會重新初始化備份節(jié)點，開銷較大
- replication（復(fù)制）：在初始化后這個操作會一直持續(xù)的進行著,以保持各個secondary節(jié)點之間的數(shù)據(jù)同步咐熙。
initial sync
當遇到上面例子中無法同步的問題時了赵，只能使用以下兩種方式進行initial sync了
- 第一種方式就是停止該節(jié)點斥废，然后刪除目錄中的文件，重新啟動該節(jié)點蛾魄。這樣弱判，這個節(jié)點就會執(zhí)行initial sync
注意：通過這種方式，sync的時間是根據(jù)數(shù)據(jù)量大小的，如果數(shù)據(jù)量過大，sync時間就會很長
同時會有很多網(wǎng)絡(luò)傳輸拉背，可能會影響其他節(jié)點的工作 - 第二種方式，停止該節(jié)點默终，然后刪除目錄中的文件椅棺，找一個比較新的節(jié)點，然后把該節(jié)點目錄中的文件拷貝到要sync的節(jié)點目錄中
