MongoDB的replication机制除了最普通的Master/Slave模式之外，更强大的就是其支持自动故障转移的ReplicaSets模式了。相对于其问题多多的auto-sharding机制，ReplicaSets还是相对比较稳定。下面学步园小编来讲解下ReplicaSets机制在4sq中有几种架构方式?
ReplicaSets机制在4sq中有几种架构方式
1.在原有的Master/Slave机制上添加一台arbiter
4sq在早期有一些Master/Slave的MongoDB架构，但这种模式不能实现自动的故障转移，需要在发生故障时手动进行切换。在ReplicaSets出现后，这种结构被迁移成为三台机器的ReplicaSets：一台Primary，一台Secondary，一台Arbiter。
迁移过程：
修改Master和slave的配置，添加如下几项，并重启MongoDB。
replSet=auxdb
fastsync=true
rest=true
fastsync使得重启动可以使用到原来的数据文件，重启会非常快。然后再在Primary上用rs.add和rs.addArb将Secondary和Arbiter添加上。就算完成了。
ReplicaSets机制在4sq中有几种架构方式
2.一个Primary用于写，多个Secondary用于读和一个Secondary用于备份
在写多读少的应用中，4sq主要使用了ReplicaSets来实现读写分离。通过在连接时指定slaveOk，将读操作放到Secondary上，Primary只承担写操作。同时指定一台priority为0，hidden为true的Secondary来进行备份(这样设置后此机器在读写中都不可见，并且不会被选举为Primary)
3.MongoDB经典配置，上层是Auto-Sharding，每个Sharding结点又是一个ReplicaSets
虽然4sq在这上面吃过亏，但很明显他们已经吸取了教训并且在更合理更小心的使用Auto-Sharding这一诱人的功能。
以上就是关于“ReplicaSets机制在4sq中有几种架构方式”的内容，希望对大家有用。更多资讯请关注学步园。学步园，您学习IT技术的优质平台!