Mongo DB 提供了集群以及分片策略，这样满足了我们大部分的场景要求。

集群搭建

先说下集群的构架， 可以从下图看到，每个APP 都是把数据写到Primary 中， 然后Primary在把数据复制给secondary中。从图中我们可以看到，只有Primary才有读写的权利，secondary 只拥有备份的权利。

那么如果万一Primary unavailable了呢？ 毕竟我们需要的是高可用的场景，那么每个节点都有heartbeat，这样就可以选举出来新的Primary。不过即使原来的主节点复活，也不会重新变为子节点。

Selection 选举

那么他们之间是如何是选举的？难道像Zookeeper 或者 Redis 一样， 用着Paxons 算法吗？  当然不是啦，他有自己的算法。

在每一个复制节点启动的时候 节点会有两个信息，一个是Votes , 一个是 Priority.

每个成员的投票数是1或者0 ， 而仲裁者总是有一票。  并且如果一个节点的Priority 大于0 ， 则他的投票数必须大于0。

并且可以最多有50个复制节点，但是最多只能有7个投票节点。

Arbiter 仲裁点

然后我们还可以添加一个仲裁节点。 仲裁节点除了投票权限意外，没有任何的作用。他会根据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台节点。

 1）加载配置文件

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}
            ]
         }

2）初始化配置 并且查询集群状态

rs.initiate(cfg)

rs.status()

可以看到如下标志。 证明集群搭建Okay。

3）同步数据

 这个时候我向主节点插入数据，希望在从节点可以看到数据， 但是并没有看到。

 看上图的错误，可以发现，是因为不是主节点，并且SlaveOk=false ， 所以我们把SlaveOk  打开就好了。

rs.slaveOk()

加入仲裁节点。

1） 插入新的节点

rs.addArb("127.0.0.1:27020")

2）查看配置文件。

rs.config()

可以看到是arbiterOnly。

Mongo DB 的集群搭建

原文：https://www.cnblogs.com/mythdoraemon/p/10301652.html