MongoDB 复制集模式Replica Sets

1、概述

复制集是一个带有故障转移的主从集群。是从现有的主从模式演变而来，增加了自动故障转移和节点成员自动恢复。

复制集模式中没有固定的主结点，在启动后，多个服务节点间将自动选举产生一个主结点。该主结点被称为primary，一个或多个从结点被称为secondaries。primary结点基本上就是master结点，不同之处在于primary结点在不同时间可能是不同的服务器。如果当前的主结点失效了，复制集中的其余结点将会试图选出一个新的主结点。

复制集模式的好处是，一切自动化。首先，复制集模式本身做了大量的管理工作，自动管理从节点，确保数据不会不一致。其次，主节点挂掉后，会自动判断集群中的服务器并进行故障转移，推举新的主节点。

一个复制集集群支持1-7台服务器，在一个复制集中各个服务器数据保持完全一致。

在一个复制集集群中，各个服务器有以下几种状态：

Primary 主节点，一个复制集有且仅有一台服务器处于Primary状态，只有主节点才对外提供读写服务。如果主节点挂掉，复制集将会投票选出一个备用节点成为新的主节点。

Secondary 备用节点，复制集允许有多台Secondary，每个备用节点的数据与主节点的数据是完全同步的。

  Recovering 恢复中，当复制集中某台服务器挂掉或者掉线后数据无法同步，重新恢复服务后从其他成员复制数据，这时就处于恢复过程，数据同步后，该节点又回到备用状态。

Arbiter 仲裁节点，该类节点可以不用单独存在，如果配置为仲裁节点，就主要负责在复本集中监控其他节点状态，投票选出主节点。该节点将不会用于存放数据。如果没有仲裁节点，那么投票工作将由所有节点共同进行。

Down 无效节点，当服务器挂掉或掉线时就会处于该状态。

复制集的从节点读请求，也是在各个Driver层设置slaveOk的值来实现的。

2、示例

同样的在一台机器上实现此功能。

（1）建立集群名字 yy

第一个节点：C盘，端口号：2222

第二个节点：E盘，端口号：3333

第三个节点：F盘，端口号：4444

（2）实例化Replica Sets

打开任意一个mongod节点，登录后执行如下内容（这里登陆C盘）：

进行初始化：

调用rs.conf（）查看配置信息

可以看到2222成了主节点，3333成了从节点，4444是仲裁节点：

调用rs.status()查看状态：

调用 rs.isMaster()查看是否是主节点：

登录 3333端口查看：

登录4444端口查看：

（3）测试

在主库中插入一节点，如下：

但此时在从库中查询报如下错误：

这是正常的现象，对于SECONDARY节点默认是不可读的。因为SECONDARY是不允许读和写的，在写多读少的应用中，使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk，由SECONDARY来分担读的压力，PRIMARY只承担些操作。

解决方法：

第一种：在从节点设置slaveOk（）：

第二种：在主节点设置：

这样就可以查询了。

同样，当主库中删除一条数据时，会同步到从库。

如果把2222端口的服务停掉，则可以看到3333会成为主节点。

此时在3333上调用rs.status（）可以看到了变化：

3333变成了主库。

以上在一台机器上配置了MongoDB的复制集模式。供大家参考。