复制策略与复制的方式

　　然而，这样做的好处是，你可以有一个更可读的日志。它也使把副服务器转为主服务器变得容易很多。最主要的是，如果你不傻的话：它们实际的操作完全是相同的一回事，但因为你是在协议层上工作，而不是文件级，所以你可以得到一些感兴趣的好处。

　　让我们假设你有相同的“大脑分裂”问题，即主副服务器都认为它自己是主服务器。在用 Log Shipping 的情况下，我们无法调和这个分歧。而在用 Oplog 的情况下，我们却可以做到。这里的关键是，我们可以：

• 对拒绝操作的服务器之一dump为可恢复状态。

• 尝试应用两个服务器上的日志，希望它们不是同时工作在同一个文档上。

　　这就是MongoDB采用的复制模式。并且它采取的处理这种冲突的第一种方法。事实上，这几乎是能够安全解决的唯一选择。当然，当两台服务器上更改相同对象是总是需要手动解决。而且最好是提前预防而不是认为“这样有时奏效”。

　　你可以在这里看到一些MongoDB如何合并交叉写的讨论。事实上，如果继续使用相同的源数据，你可以在这里看到MongoDB内部的oplog ：

   1: // Operations

   2:

   3: > use test

   4: switched to db test

   5: > db.foo.insert({x:1})

   6: > db.foo.update({x:1}, {$set : {y:1}})

   7: > db.foo.update({x:2}, {$set : {y:1}}, true)

   8: > db.foo.remove({x:1})

   9:

  10: // Op log view

  11:

  12: > use local

  13: switched to db local

  14: > db.oplog.rs.find()

  15: { "ts" : { "t" : 1286821527000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" : "initiating set" } }

  16: { "ts" : { "t" : 1286821977000, "i" : 1 }, "h" : NumberLong("1722870850266333201"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d"), "x" : 1 } }

  17: { "ts" : { "t" : 1286821984000, "i" : 1 }, "h" : NumberLong("1633487572904743924"), "op" : "u", "ns" : "test.foo", "o2" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d") }, "o" : { "$set" : { "y" : 1 } } }

  18: { "ts" : { "t" : 1286821993000, "i" : 1 }, "h" : NumberLong("5491114356580488109"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4cb3586928ce78a2245fbd57"), "x" : 2, "y" : 1 } }

  19: { "ts" : { "t" : 1286821996000, "i" : 1 }, "h" : NumberLong("243223472855067144"), "op" : "d", "ns" : "test.foo", "b" : true, "o" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d") } }

　　你可以通过在oplog实体上的命令查看链。例如，上面命令的第7行被变成18行的一个插入。这样似乎也要做很多的工作来避免做任何计算工作，更倾向于用一个简单操作来解决问题。

比如，你有一个看起来像{counter:1}的文档，你在主节点上做了一个类似{$inc:{counter:1}}的更新，结果是{counter:2}，而oplog将储存{$set:{counter:2}}。次级节点将这样复制而不是使用$inc。

　　这是一个非常不错的特性，因为你可以多次操作这样的变更，但是返回的结果是一样的。但是这样会导致一个恶劣的结果，那就是你不能将多次的变更合并处理，当然，你可以采用更好的一些方式来处理这个问题，但是。。我并不喜欢这种方案。     

Multi write partners

　　在这种模式下，我们存在一个服务器的集群，每一个服务器都很类似。所有的写操作都被处理并记录下来。当从源服务器复制到所有的目标服务器的时候，就会问目标服务器：你上次从我这儿操作了多少啦，这里就是从上次到现在的所有的变更哦。在这一点，我们可以从已经复制到所有的目标服务器的日志来看看。

　　服务器宕机意味着相关的日志变化部分会在尺度上增加，直到同伴节点再次运行起来，或者我们从复制目标中移除这个服务器条目。

　　到目前为止，这与你要组织 oplog 的方式非常相似。主要的不同是，组织需要记录的真实数据的方式。从 oplog 角度看，你准备向系统中写入发生的变化。并且，对之施行的唯一方式就是以它产生的相同顺序将其应用到 oplog 中。这会导致你只能一直拥有一个单主节点的系统。并且会引发在“大脑分裂”时数据丢失或需要手工合并的场景。

　　就多重可写组合而言，我们要保持足够的上下文（通常是所有对象），以便给用户更好的选择来解决冲突。这也在非顺序的方式中给我们一种重新回放日志的选择。

　　注意，无论如何，你都不能让一个新的服务器上线，如果你想让它一开始就运行良好的话。你必须从一个已知状态开始，通常是从一个已存在的数据库备份节点开始。像日志传送的那样，这个过程从本质上说，开始复制到（当前不存在的服务器上），当我们实际拥有新的服务器时，这将确保日志记录它们。在一个从服务器上备份和恢复数据库，然后，从源数据库那里配置接收复制。