Nosql Mongodb之旅(22)—MongoDB Replica Sets

 
 

    MongoDB支持在多个机器中通过异步复制达到故障转移和实现冗余。多机器中同一时刻只有一台机器是用于写操作,正因为如此,MongoDB提供了数据一致性的保障。而担当primary角色的机器,可以把读的操作分发给slave。

    MongoDB高可用分两种:

    Master-Slave 主从复制:

    只需要在某一个服务启动时加上–master 参数,而另一个服务加上–slave 与–source 参数,即可实现同步。MongoDB 的最新版本已不再推荐此方案。

    Replica Sets 复制集:

    MonoDB在1.6版本上开发了新功能Replica Sets,这比之前的replication功能要强大一些,增加了故障自动切换和自动修复成员节点,各个DB之间数据完全一致,大大降低了维护成本。auto shard 已经明确说明不支持replication paris,建议使用replica set。

    Replica Sets的结构非常类似一个集群。是的,你完全可以把它当作一个集群,因为它实现的功能和集群是一样的,其中一个节点如果出现故障,其它节点马上会将业务接过来,而无需停机操作。

    节点的类型:

    standard:常规节点,它存储一份完整的数据副本,参与选举投票,有可能成为primary节点。

    passive:存储了完整的数据副本,参与投票,不能成为primary节点。

    arbiter:仲裁节点,只参与投票,不接收复制的数据,也不能成为primary节点。

    一个repica sets节点数量最好为奇数(odd)。

    配置实例(三节点)

    实验是三个节点:

    两个standard节点(这两个节点直接可以互切primary secondary)。

    一个arbiter节点,它手中握着一张选票,决定上面两个standard节点中的哪一个可以成为primay。

    图例:

    配置步骤:

    1、启动三个节点

    启动第一个standard节点(ip:192.168.0.11)

    1. /mongodb/bin/mongod--dbpath=/mongodb/mongodb_date--logpath=/mongodb/mongodb_log/mongod.log--port27017--replSettest/192.168.0.12:27017--maxConns=2000--fork--logappend
    启动第二个standard节点 (ip:192.168.0.12)
    1. /mongodb/bin/mongod--dbpath=/mongodb/mongodb_date--logpath=/mongodb/mongodb_log/mongod.log--port27017--replSettest/192.168.0.11:27017--maxConns=2000--fork--logappend
    启动arbiter节点,也就是仲裁节点 (ip:192.168.0.13)。注意!--replSet test/后面写的是两个standard节点的ip和端口
    1. /mongodb/bin/mongod--dbpath=/mongodb/mongodb_date--logpath=/mongodb/mongodb_log/mongod.log--port27017--replSettest/192.168.0.11:27017,192.168.0.12:27017--fork--logappend
    参数说明:

    --dbpath 数据文件路径

    --logpath 日志文件路径

    --port 端口号,默认是27017.我这里使用的也是这个端口号.

    --replSet 复制集的名字,一个replica sets中的每个节点的这个参数都要用一个复制集名字,这里是test.

    --replSet test/ 这个后面跟的是其他standard节点的ip和端口

    --maxConns 最大连接数

    --fork后台运行

    --logappend 日志文件循环使用,如果日志文件已满,那么新日志覆盖最久日志。

    2、很关键的一步,配置完上面,下面开始初始化各个节点。在第二个启动的节点上,运行mongo

    1. db.runCommand({"replSetInitiate":{
    2. "_id":"test",
    3. "members":[
    4. {
    5. "_id":0,
    6. "host":"192.168.0.11:27017"
    7. },
    8. {
    9. "_id":1,
    10. "host":"192.168.0.12:27017"
    11. }
    12. ]}})
    3、加入arbiter节点

    1. PRIMARY>rs.addArb("192.16.0.13:27017");
    注意!!!

    添加新节点前,一定要配置好防火墙,开放对应的IP及PORT.

    添加普通数据节点:

    1. PRIMARY>rs.add("ip:port")
    删除节点

    1. PRIMARY>rs.remove("ip:port")
    显示当前谁是primary

    1. PRIMARY>rs.isMaster()
    将一个普通数据节点修改为passive节点

    除了仲裁节点,其他每个节点都有个优先权,我们可以通过设置优先权来决定谁的成为primay的权重最大。MongoDB replica sets中通过设置priority的值来决定优先权的大小,这个值的范围是0--100,值越大,优先权越高。如果值是0,那么不能成为primay。

    1、通过rs.conf()命令查看出节点列表

    1. PRIMARY>rs.conf()
    2. {
    3. "_id":"test",
    4. "version":22,
    5. "members":[
    6. {
    7. "_id":3,
    8. "host":"192.168.22.36:27017"
    9. },
    10. {
    11. "_id":5,
    12. "host":"192.168.22.10:27017"
    13. },
    14. {
    15. "_id":6,
    16. "host":"192.168.22.12:27017",
    17. "priority":0,
    18. "arbiterOnly":true
    19. },
    20. {
    21. "_id":7,
    22. "host":"192.168.22.115:27017"
    23. }
    24. ]
    25. }
    2、将上面红色的192.168.22.10节点的priority值修改成0,让它只接收数据,不参与成为primary的竞争。

    命令格式如下:

    1. cfg=rs.conf()
    2. cfg.members[0].priority=0.5
    3. cfg.members[1].priority=2
    4. cfg.members[2].priority=2
    5. rs.reconfig(cfg)
    红色中括号中的数字是执行rs.conf()得出的节点顺序,第一个节点在这里写0,第二个节点写1,依次类推。

    执行命令

    1. cfg=rs.conf()
    2. cfg.members[1].priority=0
    3. rs.reconfig(cfg)
    3.查看结果,192.168.22.10的优先权变为0.

    1. PRIMARY>rs.conf()
    2. {
    3. "_id":"test",
    4. "host":"192.168.22.10:27017"
    5. "priority":0
    6. },
    7. "host":"192.168.22.115:27017"
    8. }
    9. ]
    10. }

相关文章

一、引言 学习redis 也有一段时间了,该接触的也差不多了。后来有一天,以前的同事问我,如何向redis中...
一、引言 上一篇文章,我介绍了如何在Linux系统上安装和配置MongoDB,其实都不是很难,不需要安装和编译...
一、介绍 Redis客户端使用RESP(Redis的序列化协议)协议与Redis的服务器端进行通信。 虽然该协议是专门...
一、引言 redis学了一段时间了,基本的东西都没问题了。从今天开始讲写一些redis和lua脚本的相关的东西...
一、介绍 今天继续redis-cli使用的介绍,上一篇文章写了一部分,写到第9个小节,今天就来完成第二部分。...
一、引言 上一篇文章我们已经介绍了MongoDB数据库的查询操作,但是并没有介绍全,随着自己的学习的深入...