标签:
对于Mongo在数据容灾上,推荐的模式是使用副本集模式,它有一个对外的主服务器Primary,还有N个副本服务器Secondary(N>=1,当N=1时,需要有一台仲裁服务器Arbiter,当N>1时不需要Arbiter),它们之前是通过内部机制实现同步的,并且当Primary挂了后,它会通过内部的心跳机制,选举别一台Secondary成为一个Primary,与外界(Route)进行通讯。
在标准上,我们的副本集推荐使用奇数个服务器(3,5,7,9),但经过我的测试,只要大于两台服务器都是可以的,对于route server和config server我们都开3台server,这样在它们其中一台挂了后,可以从其它两台进行路由指向,而配置信息的使用并不多,只是在路由机启动时才去从配置机拿信息的。
Replica Set使用的是n个mongod节点,构建具备自动的容错功能(auto-failover),自动恢复的(auto-recovery)的高可用方案。也可以使用Replica Set来实现读写分离,通过在连接时指定或者在主库指定slaveOk,由Secondary来分担读的压力,Primary只承担写操作,对于Replica Set中的secondary 节点默认是不可读的,我们可以通过配置来实现它的读写功能(state:1可以读写,state:2不能读写),如果不希望secondary永远不成为primary,可以使用Priority:0,即它的优先级为0,这时它永远不会成为主节点。
secondary的读写配置:state:1可以读写,state:2不能读写
secondary的仲裁配置:arbiterOnly:true
secondary的优先级配置(成为primary的可能性):Priority:3,数字越大,优先级越高
secondary不让它投票:votes:0;
上面的图只是一个集群的逻辑架构图,而真正到物理架构还是不一样的(即每台服务器的部署及服务器与间的关系),对于两个片的集群来说,物理架构上可能需要4台服务器,2台用到replica set的primary,负责对外读和写及存储s和c(s指路由服务,c指配置服务),2台用于replica set的secondary和Arbiter(仲裁),并把它们交差部署即可,类似这样
其实上面的架构图只是一个说明,具体还要大家去实际自己去配置,去操作,只有真正操作过了,才能有权力说话!呵呵!
标签:
原文地址:http://www.cnblogs.com/lori/p/4435301.html