資訊專欄INFORMATION COLUMN
摘要：解釋首先，到底是什么意思呢在關系型數據庫中因為有事務的概念，操作數據后在沒有之前是可以執行命令進行數據回退的。
前言
前段時間突然發現數據庫文件路徑下多了個rollback名字的文件夾，很是納悶，里面居然還有.bson后綴格式的文件，隨一探究竟。
原來是在這段時間內發生過failover（主從切換），導致了某些不一致數據的丟失，這可是一個大問題啊，弄不好就是要丟數據的，
故進行了些調查研究，詳述于此；供大蝦們大繩們指點。
首先，rollback到底是什么意思呢？在關系型數據庫中因為有事務的概念，操作數據后在沒有commit之前是可以執行rollback命令進行數據回退的。
而在單實例mongodb中，寫入就寫入了，刪除就刪除了，沒有事務的概念，也沒有rollback的操作，所以這里要討論的是replicaset（復制集）的rollback
如下圖架構，在primary上執行寫操作
步驟1: 客戶端向Primary寫入3筆數據 1、2、3, 經過oplog日志后同步到secondary節點上，此時各個節點數據一致
步驟2： 但當Primary節點再次被寫入一筆數據4的時候，發生宕機，此時 數據4 還沒來得及同步到從節點上
步驟3： 此時集群短時間關閉寫操作開始競選，經過一系列選舉后有了新的primary節點，此時新Primary節點上是沒有數據4的
步驟4： 新的primary承接了客戶端的write請求，寫入新數據 5，此時新primary的數據狀態為1，2，3，5
步驟5： 原primary節點重新啟動后申請加入replica member作為secondary節點，因為此時它與新primary數據不一致，所以就會發生rollback（回滾）動作，將數據狀態恢復為1，2，3
步驟6：回滾完之后，將繼續同步新primary節點的數據，之后數據狀態變為1，2，3，5
請看下圖：
客戶端驅動在連接mongo之后進行寫操作的大致流程就是這樣的，寫操作會按照編號順序進行， 當Client收到5號的response反饋后即認為寫入成功，
而如何數據已寫入journal files，但是尚未oplog同步到Secondary節點重放，如果此時發生Primary宕機，則就會造成主從之間數據不一致，即原Primary中有
剛才新寫入的數據，但新選舉出來的Primary卻沒有那部分數據，從來造成數據丟失
綜上所述，rollback的發生，主要是Primary寫入數據后還未來得及同步到secondary節點時，發生宕機事故，導致數據缺失，
經重新選舉后產生新primary節點，但當原Primary重新加入集群時，由于要追隨新Primary節點進行強一致性處理，所以會回滾宕機前未同步的數據。
那么回滾的數據跑到哪里去了呢？當rollback發生時，MongoDB將把rollback的數據以BSON格式存放到dbpath路徑下rollback文件夾中，BSON文件的命名格式如下：
還原數據
. . .bson
那么這個rollback數據如何寫回到mongodb呢?我們可以利用mongorestore命令進行基于文件的恢復操作，具體操作可以看我另外一篇關于mongodump/mongorestore的文章
