摘要：解释首先，到底是什么意思呢在关系型数据库中因为有事务的概念，操作数据后在没有之前是可以执行命令进行数据回退的。
前言
前段时间突然发现数据库文件路径下多了个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的文章
