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

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

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

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

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

請(qǐng)看下圖：

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

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

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

...bson

那么這個(gè)rollback數(shù)據(jù)如何寫(xiě)回到mongodb呢?我們可以利用mongorestore命令進(jìn)行基于文件的恢復(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（寫(xiě)關(guān)注），也就是關(guān)心寫(xiě)操作。是在驅(qū)動(dòng)的connection level進(jìn)行配置，支持一下值：

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

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

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

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

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

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

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