MongoDB的Replicasets是一个升级版的主从机制，不同的是，它提供了一个机制，使得在主结点出现故障后其中一个从结点可以自动转移为主结点。下面学步园小编来讲解下为什么需要超过7个结点的ReplicaSets?
为什么需要超过7个结点的ReplicaSets
在我们的应用中，我们我们的每一个sharding结点是一个由四个replicasets数据结点加一个replicasetsarbiter组成。MongoDB的replicasets最多可以设置7个结点，为什么我们需要这么多的结点呢?为什么在我们的应用中，我们需要有4份数据备份呢?
在MongoDB的邮件列表里有一个讨论，其中说到Google的数据也只有3到4份备份。对于数据安全性来说，3到4份确实足够了，但是如果你想在不同地域有一份备份，那么可能3到4份就不够了。比如我们的应用，我们在不同的两个地域分别有两个备份。
为什么需要超过7个结点的ReplicaSets
我们的每一个replicaset结点都存储了400GB的数据，当一个结点出现故障后，它可能在未来某个时间点重新恢复过来，这时候他需要重新同步最新的数据。如果故障时间不长，那我们可以增量地通过主服务器的oplog来将故障时间内的更新操作同步过来执行，但是如果故障时间超过了oplog所存储的更新范围(nosqlfan：oplog的存储是在cappedcollection中，这种collection只有一定大小，超过大小后会将旧数据进行删除，所以oplog中只会有最近一段时间的更新日志。)，这这种情况下，我们必须要对数据进行全量的同步。
从异地远程全量同步，对于我们的400GB数据来说，会耗费很长的时候，大概是几天。但是由于我们在同一个机房里还存在一个节点，如果我们从这个结点进行备份，那就会很快。
也就是说，我们可以将同一机房的另一个节点停机，然后将数据备份给出现故障刚刚恢复的这个节点。同机房的数据拷贝是很快的。也就是说我们有两套恢复方案，耗时地从远端的master机器上备份或者快速地从同一机房的另一个节进行备份。
如果你的数据量没有我们这么大，那没有什么关系，但是对我们来说，必须保证在同一机房能有超过一个结点。MongoDB7个结点的限制让我们可以在三个不同地域分别设置两个结点，还剩一个节点可以做arbiter。但是在Google的最多3，4个结点的限制下，这种任务就没法完成了。
以上就是关于“为什么需要超过7个结点的ReplicaSets”的内容，希望对大家有用。更多资讯请关注学步园。学步园，您学习IT技术的优质平台!