摘要：解釋首先，到底是什么意思呢在關(guān)系型數(shù)據(jù)庫中因為有事務(wù)的概念，操作數(shù)據(jù)后在沒有之前是可以執(zhí)行命令進行數(shù)據(jù)回退的。

前段時間突然發(fā)現(xiàn)數(shù)據(jù)庫文件路徑下多了個rollback名字的文件夾，很是納悶，里面居然還有.bson后綴格式的文件，隨一探究竟。
原來是在這段時間內(nèi)發(fā)生過failover（主從切換），導(dǎo)致了某些不一致數(shù)據(jù)的丟失，這可是一個大問題啊，弄不好就是要丟數(shù)據(jù)的，
故進行了些調(diào)查研究，詳述于此；供大蝦們大繩們指點。

首先，rollback到底是什么意思呢？在關(guān)系型數(shù)據(jù)庫中因為有事務(wù)的概念，操作數(shù)據(jù)后在沒有commit之前是可以執(zhí)行rollback命令進行數(shù)據(jù)回退的。
而在單實例mongodb中，寫入就寫入了，刪除就刪除了，沒有事務(wù)的概念，也沒有rollback的操作，所以這里要討論的是replicaset（復(fù)制集）的rollback

如下圖架構(gòu)，在primary上執(zhí)行寫操作

步驟1: 客戶端向Primary寫入3筆數(shù)據(jù) 1、2、3, 經(jīng)過oplog日志后同步到secondary節(jié)點上，此時各個節(jié)點數(shù)據(jù)一致
步驟2： 但當Primary節(jié)點再次被寫入一筆數(shù)據(jù)4的時候，發(fā)生宕機，此時 數(shù)據(jù)4 還沒來得及同步到從節(jié)點上
步驟3： 此時集群短時間關(guān)閉寫操作開始競選，經(jīng)過一系列選舉后有了新的primary節(jié)點，此時新Primary節(jié)點上是沒有數(shù)據(jù)4的
步驟4： 新的primary承接了客戶端的write請求，寫入新數(shù)據(jù) 5，此時新primary的數(shù)據(jù)狀態(tài)為1，2，3，5
步驟5： 原primary節(jié)點重新啟動后申請加入replica member作為secondary節(jié)點，因為此時它與新primary數(shù)據(jù)不一致，所以就會發(fā)生rollback（回滾）動作，將數(shù)據(jù)狀態(tài)恢復(fù)為1，2，3
步驟6：回滾完之后，將繼續(xù)同步新primary節(jié)點的數(shù)據(jù)，之后數(shù)據(jù)狀態(tài)變?yōu)?，2，3，5

請看下圖：

客戶端驅(qū)動在連接mongo之后進行寫操作的大致流程就是這樣的，寫操作會按照編號順序進行， 當Client收到5號的response反饋后即認為寫入成功，
而如何數(shù)據(jù)已寫入journal files，但是尚未oplog同步到Secondary節(jié)點重放，如果此時發(fā)生Primary宕機，則就會造成主從之間數(shù)據(jù)不一致，即原Primary中有
剛才新寫入的數(shù)據(jù)，但新選舉出來的Primary卻沒有那部分數(shù)據(jù)，從來造成數(shù)據(jù)丟失

綜上所述，rollback的發(fā)生，主要是Primary寫入數(shù)據(jù)后還未來得及同步到secondary節(jié)點時，發(fā)生宕機事故，導(dǎo)致數(shù)據(jù)缺失，
經(jīng)重新選舉后產(chǎn)生新primary節(jié)點，但當原Primary重新加入集群時，由于要追隨新Primary節(jié)點進行強一致性處理，所以會回滾宕機前未同步的數(shù)據(jù)。

那么回滾的數(shù)據(jù)跑到哪里去了呢？當rollback發(fā)生時，MongoDB將把rollback的數(shù)據(jù)以BSON格式存放到dbpath路徑下rollback文件夾中，BSON文件的命名格式如下：

...bson

那么這個rollback數(shù)據(jù)如何寫回到mongodb呢?我們可以利用mongorestore命令進行基于文件的恢復(fù)操作，具體操作可以看我另外一篇關(guān)于mongodump/mongorestore的文章

mongorestore --host  --db db1 --collection c2 -u admin_user -p"123456" --authenticationDatabase admin rollback/c2_rollback.BSON

要講避免策略那就應(yīng)先講講Write Concern（寫關(guān)注），也就是關(guān)心寫操作。是在驅(qū)動的connection level進行配置，支持一下值：

* w:0 | 1 | n | majority | tag
* j:1
* wtimeout: millis

w:0 unacknowledged
驅(qū)動只是一味的進行寫入操作，不會關(guān)心是否寫入成功，也就是mongo不會返回操作結(jié)果

w:1 Acknowledged
看圖我們很容易理解，Driver在做寫入操作后會收到mongod的反饋OK還是NG，而這個反饋行為只是在確認數(shù)據(jù)被成功寫入Data Buffer,Journal Buffer
后的狀態(tài)，不保證數(shù)據(jù)能夠被寫入datafile（落盤）

J:1 Journaled
驅(qū)動寫操作不僅要寫入Journal Buffer，Data Buffer中，還要確認數(shù)據(jù)持久化到Journal file中后才反饋結(jié)果。
即使數(shù)據(jù)庫宕機，重啟后，操作已經(jīng)持久化到j(luò)ournal中，可以完全恢復(fù)，但前提是mongod一定要開啟journal參數(shù)

w:2/n/majority Replica Acknowledged
看到下圖，你應(yīng)該就明白一半了，好的，下一半讓小弟再給你解釋一下。
rollback的發(fā)生就是因為數(shù)據(jù)成功寫入Primary，但是尚未同步到Secondary節(jié)點，此時Primary宕機，
當原Primary重新加入集群后則會發(fā)生灰色數(shù)據(jù)自行rollback的現(xiàn)象，那么怎么避免呢？當然就是在發(fā)送反饋信息給驅(qū)動前
確保數(shù)據(jù)已經(jīng)更新到至少一個Secondary節(jié)點，不就完美解決此問題了。是的，使用w:2/n/majority的配置參數(shù)
就能實現(xiàn)，當然，為了防止網(wǎng)絡(luò)問題出現(xiàn)阻塞等待，我們可以設(shè)置wtimeout

應(yīng)用官方的一段話：

我的理解是rollback的數(shù)據(jù)超過300M后就需要手動干預(yù)從原Primary去除灰色數(shù)據(jù)了，但是有網(wǎng)友測試3G多的數(shù)據(jù)也能自行rollback，
So，I"m not clear the real meaning of the Limitations