程序博客网 > 匈牙利算法 指派问题

征服 Mongodb 之 主从复制&集群复制

来源：互联网 发布：匈牙利算法 指派问题 编辑：程序博客网 时间：2024/04/27 20:48

廉颇老矣，尚可饭否？然也！

Mongodb的研究总是断断续续，需要持续经营，将其积累，为日后的工作提供参考。

年底了，把今年用到的东西做个收敛。把这个年初就写了点的东西再好好收拾收拾。

今天尝试一把复制集群ReplicateSet模式，做个小总结，后续在这个帖子上不断填充。

 

集群配置相关链接：

征服 Mongodb 之 安装与系统服务配置

征服 Mongodb 之 主从复制&集群复制

 

基本操作相关链接：

征服 Mongodb 之 常用命令、基本数据类型  

征服 Mongodb 之 Modifier初识

征服 Mongodb 之 Modifier增强

征服 Mongodb 之 CRUD

 

一、主从复制

一般数据库都会用到这种最通用的模式——主从模式。这种方式简单灵活，可用于备份、故障恢复，读扩展。为了平衡负载，一般通过读写分离模式，即主库写、从库读。

 

 

假设我们有两台MongoDB服务器，10.11.20.140和10.11.20.139。如果要配置主从复制，可参考如下实现：

 

Master（10.11.20.140）：

 

Java代码  收藏代码
  1. port = 27017  
  2. dbpath = /data/db  
  3. logpath = /var/log/mongodb.log  
  4. logappend = true   
  5. journal = true  
  6. pidfile = /var/run/mongodb.pid  
  7. fork = true  
  8. master = true  

  

注意：

master=true

 

Slave（10.11.20.139）：

 

Java代码  收藏代码
  1. port=27017  
  2. dbpath = /data/db  
  3. logpath = /var/log/mongodb.log  
  4. logappend = true   
  5. journal = true  
  6. fork = true  
  7. slave = true  
  8. source = 10.11.20.140:27017  

  

 注意：

slave=true

source=10.11.20.140:27017

上述配置，即可完成Master-Slave

 

简单测试下，在Master（10.11.20.140）上写数据，在Slave（10.11.20.139）上读出。

Master写入：

 

mongo 10.11.20.140:27017
MongoDB shell version: 2.0.7
connecting to: 10.11.20.140:27017/test
> db.test.save( { a: 1 } )

 

Slave 读出：

 

mongo 10.11.20.139:27017
MongoDB shell version: 2.0.7
connecting to: 10.11.20.139:27017/test
> db.test.find()
{ "_id" : ObjectId("502cccaf2d44738c3b181391"), "a" : 1 }
>

 

 完成主从同步！

 

   注意：如果这是配置了“auth = false”，主从同步可能失败。

 

二、集群复制

主从复制虽然可以承受一定的负载压力，但这种方式仍然是一个单点，如果主库挂了，数据写入就成了风险。如果，当主库挂掉的时候，可以在访问ip不变的前提下，自动将从库作为主库使用，是不是就能避免这种风险？貌似这又涉及到Linux上的服务KeepAlive等等。

在Mongodb中，提供了一种优于主从模式的集群复制（ReplicateSet）。最理想的模式是，节点之间不分特定的主从。任何一个节点都可以是主节点primary，而其他节点都是secondary，甚至可以通过投票方式选出主节点。

一般的集群复制，可以是如下这个结构：


  

假设我们拥有3台Mongodb，192.168.158.130、192.168.158.131和192.168.158.132。我们希望这3台Mongodb能够构建ReplicateSet模式，可以依照如下操作实现：

1. 配置副本集

假设我们这里的副本集定为snowolf，需要在mongodb配置文件中进行如下配置：

Java代码  收藏代码
  1. replSet = snowolf  

   然后，我们启动这两台Mongodb，查看状态。

Java代码  收藏代码
  1. $ mongo 192.168.158.130  
  2. MongoDB shell version: 2.0.4  
  3. connecting to: 192.168.158.130/test  
  4. > rs.status()  
  5. {  
  6.         "startupStatus" : 3,  
  7.         "info" : "run rs.initiate(...) if not yet done for the set",  
  8.         "errmsg" : "can't get local.system.replset config from self or any seed (EMPTYCONFIG)",  
  9.         "ok" : 0  
  10. }  
  11. >   

    这时候，复制集群还没有达到可用，需要进一步配置。

2. 配置成员

   这里可以在任一节点进行，通过rs.initiate(cfg)完成配置。

   先配置一个中间变量：

Java代码  收藏代码
  1. > cfg={_id:'snowolf',members:[   
  2. ... {_id:0,host:'192.168.158.130:27017'},  
  3. ... {_id:1,host:'192.168.158.131:27017'}]  
  4. ... }  
  5. {  
  6.         "_id" : "snowolf",  
  7.         "members" : [  
  8.                 {  
  9.                         "_id" : 0,  
  10.                         "host" : "192.168.158.130:27017"  
  11.                 },  
  12.                 {  
  13.                         "_id" : 1,  
  14.                         "host" : "192.168.158.131:27017"  
  15.                 }  
  16.         ]  
  17. }  

 接下来，需要让配置生效：

Java代码  收藏代码
  1. > rs.initiate(cfg)  
  2. {  
  3.         "info" : "Config now saved locally.  Should come online in about a minute.",  
  4.         "ok" : 1  
  5. }  

如果如上所示，说明配置成功。

这时候，再看看当前的状态：

Java代码  收藏代码
  1. > rs.status()  
  2. {  
  3.         "set" : "snowolf",  
  4.         "date" : ISODate("2013-11-14T08:33:58Z"),  
  5.         "myState" : 1,  
  6.         "members" : [  
  7.                 {  
  8.                         "_id" : 0,  
  9.                         "name" : "192.168.158.130:27017",  
  10.                         "health" : 1,  
  11.                         "state" : 1,  
  12.                         "stateStr" : "PRIMARY",  
  13.                         "optime" : {  
  14.                                 "t" : 1384417894000,  
  15.                                 "i" : 1  
  16.                         },  
  17.                         "optimeDate" : ISODate("2013-11-14T08:31:34Z"),  
  18.                         "self" : true  
  19.                 },  
  20.                 {  
  21.                         "_id" : 1,  
  22.                         "name" : "192.168.158.131:27017",  
  23.                         "health" : 1,  
  24.                         "state" : 2,  
  25.                         "stateStr" : "SECONDARY",  
  26.                         "uptime" : 137,  
  27.                         "optime" : {  
  28.                                 "t" : 1384417894000,  
  29.                                 "i" : 1  
  30.                         },  
  31.                         "optimeDate" : ISODate("2013-11-14T08:31:34Z"),  
  32.                         "lastHeartbeat" : ISODate("2013-11-14T08:33:57Z"),  
  33.                         "pingMs" : 348  
  34.                 }  
  35.         ],  
  36.         "ok" : 1  
  37. }  

 我们在一开始，并没有强制设定哪个IP是primary节点，哪个是secondary节点。这完全由Mongodb集群来决定。

这时在命令行下，提示符也发生了变化。

Primary节点：

Java代码  收藏代码
  1. PRIMARY>   

Secondary节点：

Java代码  收藏代码
  1. SECONDARY>   

别急，这时候还没有大功告成，如果直接在secondary上操作，会发生如下错误：

Java代码  收藏代码
  1. SECONDARY> db.t.find()  
  2. error: { "$err" : "not master and slaveok=false", "code" : 13435 }  

需要告知Mongodb集群，从哪台机器上进行读操作：

Java代码  收藏代码
  1. SECONDARY> rs.slaveOk()  
  2. not master and slaveok=false  

 这时就不会有刚才的错误了。

测试：

在primary节点写入操作：

Java代码  收藏代码
  1. PRIMARY> db.t.insert({uid:12345})  
  2. PRIMARY> db.t.find()  
  3. { "_id" : ObjectId("52848f782c6dd18b00fdf65d"), "uid" : 12345 }  

 在secondary节点读操作：

Java代码  收藏代码
  1. SECONDARY> db.t.find()  
  2. { "_id" : ObjectId("52848f782c6dd18b00fdf65d"), "uid" : 12345 }  

 

似乎大功告成，如果这时候我们把primary节点停掉，在secondary节点执行写操作，就会发生如下错误提示：

Java代码  收藏代码
  1. SECONDARY> db.t.insert({uid:12345})  
  2. not master  

 如果只有2台Mongodb，配置复制集群还不够安全，需要1个外在角色调整各个节点的角色。



  这些节点包括：

  1. statndard 常规节点，存储一份完整的数据副本，参与投票，可以成为活跃节点，即primary节点
  2. passive 只做存储，参与投票
  3. arbiter 仲裁者只投票，不复制数据，也不能成为活跃节点

当Primary宕掉后，可以通过Arbiter在Secodarys中选举一个Primary节点，避免单点故障。

 

现在，我们可以增加一个仲裁节点，只负责仲裁，不做数据存储。

Java代码  收藏代码
  1. PRIMARY> rs.addArb("192.168.158.132:27017")  
  2. { "ok" : 1 }  

 仲裁节点命令行提示：

 

Java代码  收藏代码
  1. ARBITER>   
  

这时候，再看各个节点的状态，也发生了变化：

Java代码  收藏代码
  1. PRIMARY> rs.status()  
  2. {  
  3.         "set" : "snowolf",  
  4.         "date" : ISODate("2013-11-14T09:07:39Z"),  
  5.         "myState" : 1,  
  6.         "members" : [  
  7.                 {  
  8.                         "_id" : 0,  
  9.                         "name" : "192.168.158.130:27017",  
  10.                         "health" : 1,  
  11.                         "state" : 2,  
  12.                         "stateStr" : "SECONDARY",  
  13.                         "uptime" : 390,  
  14.                         "optime" : {  
  15.                                 "t" : 1384420036000,  
  16.                                 "i" : 1  
  17.                         },  
  18.                         "optimeDate" : ISODate("2013-11-14T09:07:16Z"),  
  19.                         "lastHeartbeat" : ISODate("2013-11-14T09:07:39Z"),  
  20.                         "pingMs" : 1  
  21.                 },  
  22.                 {  
  23.                         "_id" : 1,  
  24.                         "name" : "192.168.158.131:27017",  
  25.                         "health" : 1,  
  26.                         "state" : 1,  
  27.                         "stateStr" : "PRIMARY",  
  28.                         "optime" : {  
  29.                                 "t" : 1384420036000,  
  30.                                 "i" : 1  
  31.                         },  
  32.                         "optimeDate" : ISODate("2013-11-14T09:07:16Z"),  
  33.                         "self" : true  
  34.                 },  
  35.                 {  
  36.                         "_id" : 2,  
  37.                         "name" : "192.168.158.132:27017",  
  38.                         "health" : 1,  
  39.                         "state" : 7,  
  40.                         "stateStr" : "ARBITER",  
  41.                         "uptime" : 23,  
  42.                         "optime" : {  
  43.                                 "t" : 1384419192000,  
  44.                                 "i" : 1  
  45.                         },  
  46.                         "optimeDate" : ISODate("2013-11-14T08:53:12Z"),  
  47.                         "lastHeartbeat" : ISODate("2013-11-14T09:07:38Z"),  
  48.                         "pingMs" : 295147904  
  49.                 }  
  50.         ],  
  51.         "ok" : 1  
  52. }  

 如果这时候，我们把primary节点停掉，是否还会影响集群的稳定性？

由于存在arbiter节点，如果primary节点宕掉，剩余的secondary会被选为primary节点，继续提供服务。酷

 

至此，主从复制、集群复制完成配置。

 

疑问，这个小集群里，是如何判断谁是Master节点、Primary节点呢？

对比三个节点对自身节点性质的判断：

Primary：

 

Java代码  收藏代码
  1. PRIMARY> db.isMaster()  
  2. {  
  3.         "setName" : "snowolf",  
  4.         "ismaster" : true,  
  5.         "secondary" : false,  
  6.         "hosts" : [  
  7.                 "192.168.158.130:27017",  
  8.                 "192.168.158.131:27017"  
  9.         ],  
  10.         "arbiters" : [  
  11.                 "192.168.158.132:27017"  
  12.         ],  
  13.         "primary" : "192.168.158.130:27017",  
  14.         "me" : "192.168.158.130:27017",  
  15.         "maxBsonObjectSize" : 16777216,  
  16.         "ok" : 1  
  17. }  
Secondary：

 

Java代码  收藏代码
  1. SECONDARY> db.isMaster()  
  2. {  
  3.         "setName" : "snowolf",  
  4.         "ismaster" : false,  
  5.         "secondary" : true,  
  6.         "hosts" : [  
  7.                 "192.168.158.131:27017",  
  8.                 "192.168.158.130:27017"  
  9.         ],  
  10.         "arbiters" : [  
  11.                 "192.168.158.132:27017"  
  12.         ],  
  13.         "primary" : "192.168.158.130:27017",  
  14.         "me" : "192.168.158.131:27017",  
  15.         "maxBsonObjectSize" : 16777216,  
  16.         "ok" : 1  
  17. }  

 Arbiter：

Java代码  收藏代码
  1. ARBITER> db.isMaster()  
  2. {  
  3.         "setName" : "snowolf",  
  4.         "ismaster" : false,  
  5.         "secondary" : false,  
  6.         "hosts" : [  
  7.                 "192.168.158.131:27017",  
  8.                 "192.168.158.130:27017"  
  9.         ],  
  10.         "arbiters" : [  
  11.                 "192.168.158.132:27017"  
  12.         ],  
  13.         "primary" : "192.168.158.130:27017",  
  14.         "arbiterOnly" : true,  
  15.         "me" : "192.168.158.132:27017",  
  16.         "maxBsonObjectSize" : 16777216,  
  17.         "ok" : 1  
  18. }  

 

我想，大家应该看明白了。酷访问任意节点，都可以找到活跃节点的IP。

 

集群配置相关链接：

征服 Mongodb 之 安装与系统服务配置

征服 Mongodb 之 主从复制&集群复制

 

基本操作相关链接：

征服 Mongodb 之 常用命令、基本数据类型  

征服 Mongodb 之 Modifier初识

征服 Mongodb 之 Modifier增强

征服 Mongodb 之 CRUD

  • 查看图片附件
0 0
匈牙利算法 指派问题 匈牙利算法 指派问题
原创粉丝点击
热门IT博客
exo什么意思网络用语exo什么意思网络用语
域名被注册有什么坏处域名被注册有什么坏处
数据库游标是什么
mac抹掉u盘失败
开源软件风险
收视率惨淡知乎
c语言中的int
订餐软件排行
预算通软件下载
知乎 离火得花
什么虚拟机可以装mac
淘宝客好赚钱吗
ubuntu搜索不到wifi
mac怎样卸载程序
今天电信网络怎么了
网络直播 分析评论
php多维数组去除重复
金山毒霸数据恢复账号
淘宝分销怎么发货模板
python 数据框加一列
热门问题 老师的惩罚 人脸识别 我在镇武司摸鱼那些年 重生之率土为王 我在大康的咸鱼生活 盘龙之生命进化 天生仙种 凡人之先天五行 春回大明朝 姑娘不必设防，我是瞎子 买菜小推车 新塘买菜网 网上买菜的网站 买什么菜好呢 在家吃火锅买什么菜 在线买菜 菜市场买菜 网上怎么买菜 买菜的网站 买菜送货上门 代买菜 买菜网招聘 怎么买菜 买菜小拉车 买菜购物车 买菜手推车 妈妈带我去买菜 去菜市场买菜 什么菜好吃 莕菜 怎么在网上买菜 买什么菜好 作文买菜 网上买菜app 网上 买菜 烧烤买什么菜 冒菜都有什么菜 冒菜是哪里的菜 网上如何买菜 老年人买菜手推车 做梦买菜 买菜哪个网站好 买菜去哪个网站 如何在网上买菜 网上买菜怎么样 可以买菜的app 网上买菜便宜 有什么菜 二人转买菜 10元钱买菜 10块钱能买什么菜

程序博客网，程序员的互联网技术博客家园。csdn论坛精品 msdn技术资料都在这里