漫漫长路,其修远兮!
分类: NOSQL
2014-07-02 16:27:39
作为MongoDB使用大户,Foursquare(简称4sq) 在MongoDB使用上有相当丰富的经验,下面是4sq的一篇文章,描述了Replica Sets机制在4sq 中的几种架构方式。
原文链接:
4sq 在早期有一些Master/Slave的MongoDB架构,但这种模式不能实现自动的故障转移,需要在发生故障时手动进行切换。在Replica Sets出现后,这种结构被迁移成为三台机器的Replica Sets:一台Primary,一台Secondary,一台Arbiter。
迁移过程:
修改Master和slave的配置,添加如下几项,并重启MongoDB。
replSet = auxdb
fastsync = true
rest = true
fastsync 使得重启动可以使用到原来的数据文件,重启会非常快。然后再在Primary上用rs.add 和 rs.addArb 将Secondary和Arbiter添加上。就算完成了。
在写多读少的应用中,4sq主要使用了Replica Sets来实现读写分离。通过在连接时指定slaveOk,将读操作放到Secondary上,Primary只承担写操作。同时指定一台priority为0,hidden为true的Secondary来进行备份(这样设置后此机器在读写中都不可见,并且不会被选举为Primary)
虽然4sq在这上面吃过亏,但很明显他们已经吸取了教训并且在更合理更小心的使用Auto-Sharding这一诱人的功能。