mongodb 丢数据的说法已经出现很久很久了，传言甚多。这里简单总结下场景。 1.在MongoDB很早的版本，2.0之前，没有journal,加上默认不是安全写，系统一宕机就可能出现数据丢失，因为数据没有刷盘，也没有恢复日志恢复机制。这个问题倒默认启用journal以及安
mongodb 丢数据的说法已经出现很久很久了，传言甚多。这里简单总结下场景。
1.在MongoDB很早的版本，2.0之前，没有journal,加上默认不是安全写，系统一宕机就可能出现数据丢失，因为数据没有刷盘，也没有恢复日志恢复机制。这个问题倒默认启用journal以及安全写之后，没有问题了。
2.选举机制造成的数据丢失。这里主要说这个。简单讲，MongoDB目前的选举机制是有缺陷的。在一些场景下会造成数据丢失。这些场景实际中会出现，如多机房情况下，但一般不会太多。
场景1
replica set有如下节点： n1, n2, n3, n4, n5
n1 主节点
n2,n3从n1同步
n4,n5从n3同步
假设发生如下事件：
- (n1, n2)与(n3, n4, n5)之间发生网络分裂（network partition）
- n3连不到n1，然后选举它自己
- n4 n5 投票给 n3, 因此n3 变成主节点
- n3执行写操作A，然后复制到n4，n5并确认，这样被复制集大部分成员确认了。
- n1 重新连接到复制集, 但仍然是主节点. 它必须降级.
现在有2个主节点 n1 and n3.其中一个需要降级，如果 n1降级，不会产生什么后果, 但如果 n3 降级, 多数成员确认的写操作就丢失了.
MongoDB 2.4中这是非常可能的. 双主场景中,选择哪一个主节点降级是随意的. SERVER-9765 描述了这个问题. 现在 2.6版本中,其中一个主节点根据上一次选举的时间戳来决定哪一个降级.上面例子中 n3被选举为主的时间比 n1近, n3应该保持作为主而n1应该降级. 因为成员可能每30秒参与一次选举，因此成功的选举之间最小间隔为30秒. 虽然如此，我仍然不知道不同成员之间的时钟误差在这个算法上如何影响。
场景2
- (n1, n2)与(n3, n4, n5)之间发生网络分裂（network partition）
- n3连不到n1，然后选举它自己
- n4 n5 投票给 n3, 因此n3 变成主节点
- n3执行写操作A，然后复制到n4，n5并确认，这样被复制集大部分成员确认了。
- n1 重新连接到复制集, 但仍然是主节点. 它必须降级.
- n1接受写操作B,然后复制并被n2确认；
- n4停止从n3复制并开始从n1复制；
- 因为n1没有写操作A，n4回滚写操作A，然后复制并确认写操作B.
这里问题就是有两个主，任意一个降级，都要回滚相应的写操作。这个例子也可以看出MongoDB复制的一个潜在问题，即简单的以来时间戳来决定oplog位置。
场景3
这个场景与2有点类似，但是考虑一下降级的时候考虑选举的时间，即选最近选举出来的为主，另一个主降级。
- 所有从节点从n1复制.
- 发生网裂，(n1, n2) 与 (n3, n4, n5)断开
- n3连不到n1，然后选举它自己
- n4 n5 投票给 n3, 但n3还没变为主节点
- n4和n5投票后，网络恢复
- n1发生写操作A，并被n2,n4,n5确认，n3还没变成主或者还没复制并确认这个写操作。
- n3最终成为主了，还没机会复制并确认A操作
- n1注意到n3是主并且选举的时间更近，因此n1降级
- 所有成员开始从n3复制，因此回滚A操作。
这里可以看出的问题是，写确认操作和投票选举操作之间并没有足够的交流，n4,n5投票给n3，确认了一个可能回滚的写操作，部分原因是因为刚刚完成选举操作。这是MongoDB选举协议没有考虑的地方。
总的来说，现在MongoDB的选举协议问题如下：
双主的情况下，必须解决一下问题
- 两个主节点必须不能产生交错的oplog
- 当双主情况下，oplog位置小的降级
数据同步线程和写确认操作线程必须与选举主节点线程有更多交流，简言之，应该如下：
- 成员不能投票会回滚写操作的节点为主节点；
- 成员不能确认因为选举投了赞成票可能造成回滚的写操作。
tokumx将通过ark选举协议来解决这个问题。
参考：
http://www.tokutek.com/2014/07/explaining-ark-part-3-why-data-may-be-lost-on-a-failover/
原文地址：为什么MongoDB会丢数据, 感谢原作者分享。
