为什么需要超过7个结点的Replica Sets?
本文是一篇译文,原文见到boxedice公司的官方博客,他们在应用中使用了MongoDB 的 replica sets机制,但不仅是为了数据的安全性,因此replica sets 7个节点的限制在这里显得尤为有用。下面我们来看一下他们的使用经验吧。
原文链接:When would ever need more than 7 replica set members?
MongoDB 的Replica sets是一个升级版的主从机制,不同的是,它提供了一个机制,使得在主结点出现故障后其中一个从结点可以自动转移为主结点。在我们的应用中,我们我们的每一个sharding结点是一个由四个replica sets数据结点加一个replica sets arbiter组成。MongoDB 的replica sets最多可以设置7个结点,为什么我们需要这么多的结点呢?为什么在我们的应用中,我们需要有4份数据备份呢?
在MongoDB 的邮件列表里有一个讨论,其中说到Google的数据也只有3到4份备份。对于数据安全性来说,3到4份确实足够了,但是如果你想在不同地域有一份备份,那么可能3到4份就不够了。比如我们的应用,我们在不同的两个地域分别有两个备份。
Why?
我们的每一个replica set结点都存储了400GB的数据,当一个结点出现故障后,它可能在未来某个时间点重新恢复过来,这时候他需要重新同步最新的数据。如果故障时间不长,那我们可以增量地通过主服务器的oplog来将故障时间内的更新操作同步过来执行,但是如果故障时间超过了oplog所存储的更新范围(nosqlfan:oplog的存储是在capped collection中,这种collection只有一定大小,超过大小后会将旧数据进行删除,所以oplog中只会有最近一段时间的更新日志。),这这种情况下,我们必须要对数据进行全量的同步。
从异地远程全量同步,对于我们的400GB数据来说,会耗费很长的时候,大概是几天。但是由于我们在同一个机房里还存在一个节点,如果我们从这个结点进行备份,那就会很快。
也就是说,我们可以将同一机房的另一个节点停机,然后将数据备份给出现故障刚刚恢复的这个节点。同机房的数据拷贝是很快的。也就是说我们有两套恢复方案,耗时地从远端的master机器上备份或者快速地从同一机房的另一个节进行备份。
如果你的数据量没有我们这么大,那没有什么关系,但是对我们来说,必须保证在同一机房能有超过一个结点。MongoDB 7个结点的限制让我们可以在三个不同地域分别设置两个结点,还剩一个节点可以做arbiter。但是在Google的最多3,4个结点的限制下,这种任务就没法完成了。
—————-本站观点—————–
其实MongoDB提供的replica sets机制,从来都不是为了不同IDC之间的类似于CDN一样的功能服务的,他看重的仅仅是数据的安全性,对于多IDC的内容同步,我想我们应该更多的通过应用层来保证,而且鉴于天朝这种让人发指的网络状况,在公司没有花大价租用专用通道的前提下,这种依靠replica sets来做数据分发的想法更不切实际。
所以在这里奉劝各位,最好是按照开发者的意图去使用特定的功能,这样也是使你的功能能够得开发者持续支持的好习惯。
|