MongoDB复制集内部数据同步

一 数据同步 一个健康的secondary在运行时，会选择一个离自己最近的，数据比自己新的节点进行数据同步。选定节点后，它会从这个节点拉取oplog同步日志，具体流程是这样的： a.执行这个op日志 b.将这个op日志写入到自己的oplog中(local.oplog.rs) c.再请求下

一 数据同步

一个健康的secondary在运行时，会选择一个离自己最近的，数据比自己新的节点进行数据同步。选定节点后，它会从这个节点拉取oplog同步日志，具体流程是这样的： a.执行这个op日志 b.将这个op日志写入到自己的oplog中(local.oplog.rs)
c.再请求下一个op日志
如果同步操作在第1步和第2步之间出现问题宕机，那么secondary再重新恢复后，会检查自己这边最新的oplog，由于第2步还没有执行，所以自己这边还没有这条写操作的日志。这时候他会再把刚才执行过的那个操作执行一次。那对同一个写操作执行两次会不会有问题呢？MongoDB在设计oplog时就考虑到了这一点，所以所有的oplog都是可以重复执行的，比如你执行 {$inc:{counter:1}} 对counter字段加1，counter字段在加1 后值为2，那么在oplog里并不会记录 {$inc:{counter:1}} 这个操作，而是记录 {$set:{counter:2}}这个操作。所以无论多少次执行同一个写操作，都不会出现问题。
注：从节点不一定要从主节点的操作日志来读取数据，它也可以选择距离自己最近的（根据ping的时间来计算）的且比自己操作日志记录更新的从节点获取操作日志。

二 同步过程

当我们在MongoDB时执行一个写操作时，默认会直接返回成功，同时也可以通过设置w参数，指定这个写操作同步到几个节点后才返回成功。如下：

db.foo.runCommand({getLastError:1, w:2})

上面例子就是执行getLastError命令，使其在上一个写操作同步到两个节点上后再返回。不同的客户端可能在写法上不太一样，不过这个功能应该都是有的。对于重要数据，可以考虑采用这样的方式，通过牺牲一部分写性能来提升数据的安全性。

这个功能是如何实现的呢，primary节点是如何知道数据同步了几份呢？在调用上面命令时，实际上MongoDB内部执行了如下的一些流程：
a.在primary上完成写操作
b.在primary上记录一条oplog日志，日志中包含一个ts字段，值为写操作执行的时间，比如本例中记为t
c.客户端调用{getLastError:1, w:2}命令等待primary返回结果
d.secondary从primary拉取oplog，获取到刚才那一次写操作的日志
e.secondary按获取到的日志执行相应的写操作
f.执行完成后，secondary再获取新的日志，其向primary上拉取oplog的条件为{ts:{$gt:t}}
g.primary此时收到secondary的请求，了解到secondary在请求时间大于t的写操作日志，所以他知道操作在t之前的 日志都已经成功执行了
h.这时候getLastError命令检测到primary与secondary都完成了这次写操作，于是 w:2 的条件满足了，返回给客户端成功