1、概述
复制集是一个带有故障转移的主从集群。是从现有的主从模式演变而来,增加了自动故障转移和节点成员自动恢复。
复制集模式中没有固定的主结点,在启动后,多个服务节点间将自动选举产生一个主结点。该主结点被称为primary,一个或多个从结点被称为secondaries。primary结点基本上就是master结点,不同之处在于primary结点在不同时间可能是不同的服务器。如果当前的主结点失效了,复制集中的其余结点将会试图选出一个新的主结点。
复制集模式的好处是,一切自动化。首先,复制集模式本身做了大量的管理工作,自动管理从节点,确保数据不会不一致。其次,主节点挂掉后,会自动判断集群中的服务器并进行故障转移,推举新的主节点。
一个复制集集群支持1-7台服务器,在一个复制集中各个服务器数据保持完全一致。
在一个复制集集群中,各个服务器有以下几种状态:
Primary 主节点,一个复制集有且仅有一台服务器处于Primary状态,只有主节点才对外提供读写服务。如果主节点挂掉,复制集将会投票选出一个备用节点成为新的主节点。
Secondary 备用节点,复制集允许有多台Secondary,每个备用节点的数据与主节点的数据是完全同步的。
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的复制集模式。供大家参考。