mongo——复制

复制

复制是跨多个mongodb服务器（节点）分布和维护数据的方法。mongodb可以把数据从一个节点复制到其他节点并在修改时进行同步。这种类型的复制通过一个叫可复制集的机制提供。集群中的节点配置为自动同步数据，并且在服务器出错时自动灾备。mongodb也提供对于旧的复制方法的支持。这个旧方法叫做主从模式，现在已经过时了，但是主从复制仍然可以在mongodb3.0里使用。两种方法类似，主节点接受所有的写请求，然后所有的从节点读取，并且异步同步所有的数据。

主从复制和可复制集群使用了相同的复制机制，但是可复制集群额外增加了自动化灾备机制：如果主节点宕机，无论什么原因，其中一个从节点会自动提升为主节点。除此之外，可复制集群还提供了其他改进，比如更容易恢复和更复杂地部署拓扑网络。因此我们很少再用简单的主从复制机制。可复制集群是推荐的生产环境下的复制策略。

复制的缺点：回滚机制，在可复制集群里，数据并非正在地被提交，直到它被写入大多数集群的节点中，这指的是50%上的服务器。因此，如果可复制集群只有两个服务器，就意味着每一服务器可以停机。如果主节点在复制数据之前停机，其他成员会继续接受写入，而且任意未复制的数据必须回滚，意味着他不能被读取。

为什么复制很重要

所有的数据库都无法摆脱环境故障的影响

1.应用程序和数据库之前的连接丢失了

2.计划内停止阻止了服务器按照预期上线

复制的使用场景和限制

复制首先是为冗余设计的。它可以确保从节点与主节点的数据同步。这些复制节点可以和主节点位于一个数据中心或者为了安全可以分布于其他数据中心。

复制是异步的，任何网络延迟和分区都不会影响主节点的性能。

作为另外一种形式的冗余，复制节点也可以延迟某个固定的时间后执行。这防止了用户无意删除集合或者应用程序与数据库冲突的情况。通常，这些操作将会被立即复制；延迟复制可以给管理员足够的时间来做出响应并保存数据。

另外一个复制的使用情况是灾备，我们希望系统是高可用的，但是只有在冗余节点时才可以使用，并且在紧急情况下切换这些节点。mongodb的可复制集群让这一切都可以自动切换。

除了数据冗余和灾备，复制也简化了维护工作，通常通过允许管理员在从节点而不是主节点上运行命令。例如，通常的经验是在从节点上运行备份命令来缓解对于主节点的压力，避免宕机。构建大型索引是另外一个例子。因为所有构建非常昂贵，我们可以在从节点上优先构建，然后切换主从节点的角色，再次在新的从节点上构建索引。

最后，复制可以允许我们从节点上平衡读写压力。对于读取压力超大的应用系统，这个是最简单的解决办法，或者如果你选择最原始的做法，可以伸缩mongodb数据库。但是对于所有的承诺，可复制集群在以下情况下无能为力：

1.现有的硬件无法处理工作负荷，例如，我们前面章节提到的工作集，如果数据集超过了可用的内存大小，那么随机读取从节点就不会像我们期望的那样改善性能。从可复制集群从节点读数据可以增加IOPS数量，但是100-200IOPS可能无法解决性能问题，特别是同时写入并消耗部分IO数量的时候，此时，分片可能是最好的选择。

2.写入和读取的比例超过50%

3.应用程度需要一致性读取。从节点异步复制，因此不能确保反映最新主节点的写入数据。在极端的糟糕的情况下&#x