标签:ons 查询 info priority color 要求 部分 stat div
Mongo DB 提供了集群以及分片策略,这样满足了我们大部分的场景要求。
先说下集群的构架, 可以从下图看到,每个APP 都是把数据写到Primary 中, 然后Primary在把数据复制给secondary中。从图中我们可以看到,只有Primary才有读写的权利,secondary 只拥有备份的权利。
那么如果万一Primary unavailable了呢? 毕竟我们需要的是高可用的场景,那么每个节点都有heartbeat,这样就可以选举出来新的Primary。不过即使原来的主节点复活,也不会重新变为子节点。
那么他们之间是如何是选举的?难道像Zookeeper 或者 Redis 一样, 用着Paxons 算法吗? 当然不是啦,他有自己的算法。
在每一个复制节点启动的时候 节点会有两个信息,一个是Votes , 一个是 Priority.
每个成员的投票数是1或者0 , 而仲裁者总是有一票。 并且如果一个节点的Priority 大于0 , 则他的投票数必须大于0。
并且可以最多有50个复制节点,但是最多只能有7个投票节点。
然后我们还可以添加一个仲裁节点。 仲裁节点除了投票权限意外,没有任何的作用。他会根据Secondary 的Priority 的大小进行投票。
好了,那么我们开始我们的构建之旅。
首先,我要有4个节点,一个Primary节点,两个secondary节点,一个仲裁节点。
主节点
dbpath=/data/mongodb/master
port=27017
fork=true
logpath=/data/mongodb/master/master.log
replSet=mythCluster
从节点1
dbpath=/data/mongodb/slave1
port=27018
fork=true
logpath=/data/mongodb/slave1/slave1.log
replSet=mythCluster
从节点2
dbpath=/data/mongodb/slave2
port=27019
fork=true
logpath=/data/mongodb/slave2/slave2.log
replSet=mythCluster
arbiter 节点
dbpath=/data/mongodb/arbiter port=27020 fork=true logpath=/data/mongodb/arbiter/arbiter.log
replSet=mythCluster
我们先启动前3个节点。
这时候我们可以看到启动了3台节点。
var cfg ={"_id":"mythCluster",
"protocolVersion" : 1,
"members":[
{"_id":0,"host":"127.0.0.1:27017","priority":10},
{"_id":1,"host":"127.0.0.1:27018","priority":2},
{"_id":2,"host":"127.0.0.1:27019","priority":0}
]
}
rs.initiate(cfg)
rs.status()
可以看到如下标志。 证明集群搭建Okay。
这个时候我向主节点插入数据,希望在从节点可以看到数据, 但是并没有看到。
看上图的错误,可以发现,是因为不是主节点,并且SlaveOk=false , 所以我们把SlaveOk 打开就好了。
rs.slaveOk()
rs.addArb("127.0.0.1:27020")
rs.config()
可以看到是arbiterOnly。
标签:ons 查询 info priority color 要求 部分 stat div
原文地址:https://www.cnblogs.com/mythdoraemon/p/10301652.html