MongoDB复制集架构
mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。
mongodb各个节点常见的搭配方式为：一主一从、一主多从。
主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。
MongoDB复制结构图如下所示：
副本集特征：
N 个节点的集群
任何节点可作为主节点
所有写入操作都在主节点上
自动故障转移
自动恢复
Replica Set角色
Replica Set 的成员是一堆有着同样的数据内容 mongod 的实例集合，包含以下三类角色：
主节点（Primary）
是 Replica Set 中唯一的接收写请求的节点，并将写入指令记录到 oplog 上。副本节点通过复制 oplog 的写入指令同步主节点的数据。Secondary。一个 Replica Set 有且只有Primary 节点，当Primar挂掉后，其他 Secondary 或者 Arbiter 节点会重新选举出来一个主节点。应用程序的默认读取请求也是发到 Primary节点处理的。
副本节点（Secondary）
通过复制主节点 oplog 中的指令与主节点保持同样的数据集，当主节点挂掉的时候，参与主节点选举。
仲裁者（Arbiter）
不存储实际应用数据，只投票参与选取主节点，但不会被选举成为主节点。
复制集架构配置：
架构：
Arbite：127.0.0.1:27017
primary：127.0.0.1:27018
secondary： 127.0.0.1:27019
配置文件内容如下，只要修改logpath、dbpath、pidfilepath和端口即可
arbiter.conf
primary.conf
secondary.conf
分别启动这三个实例：
初始化：
使用mongodb客户端登陆两个常规节点（primary和secondary）中的任何一个，执行如下命令
登陆后执行初始化命令
查看集群状态：
登录127.0.0.1:27019 角色显示为Secondary
在primary上创建数据，测试secondary上是否会同步
登录secondary，查看
secondary上插入数据报错，说明secondary上没有写的权限
验证复制集架构容灾功能
kill掉primary的进程，登录127.0.0.1:27019
可以看到127.0.0.1:27018 有一个 "stateStr" : "(not reachable/healthy)"的报错，而127.0.0.1:27019已经变成了primary角色
启动原来的primary.conf配置的实例，角色由原来的primary变成了secondary
其他命令： rs.help()
rs.slaveOk()：secondary默认不允许读写，执行此命令后，从节点有可读权限
rs.conf()：查看配置情况
rs.add()：新增一个节点到副本集中,注意只能在primary上操作，secondary角色执行该命令会报错，例如：
test-set:SECONDARY> rs.add("127.0.0.1:27020")
测试：
登录primary，新建一个third.conf的配置文件，并启动实例，端口为127.0.0.1:27020
添加新的secondary角色
rs.remove(hostportstr)：删除一个secondary节点
编辑修改集群配置(只能在primary节点上操作)
登录到MongoDB的primary实例
执行cfg=rs.conf()命令，将集群配置保存在cfg变量中
查看集群第一个成员的配置
修改第一个成员的优先级配置
保存配置使生效