Mongodb集群搭建的三种方式

 Mongodb是时下流行的NoSql数据库,它的存储方式是文档式存储,并不是Key-Value形式。关于Mongodb的特点,这里就不多介绍了,大家可以去看看官方说明:http://docs.mongodb.org/manual/

 

       今天主要来说说Mongodb的三种集群方式的搭建:Replica Set / Sharding / Master-Slaver。这里只说明最简单的集群搭建方式(生产环境),如果有多个节点可以此类推或者查看官方文档。OS是Ubuntu_x64系统,客户端用的是Java客户端。Mongodb版本是mongodb-linux-x86_64-2.2.2.tgz

 

Replica Set

       中文翻译叫做副本集,不过我并不喜欢把英文翻译成中文,总是感觉怪怪的。其实简单来说就是集群当中包含了多份数据,保证主节点挂掉了,备节点能继续提供数据服务,提供的前提就是数据需要和主节点一致。如下图:

       Mongodb(M)表示主节点,Mongodb(S)表示备节点,Mongodb(A)表示仲裁节点。主备节点存储数据,仲裁节点不存储数据。客户端同时连接主节点与备节点,不连接仲裁节点。

       默认设置下,主节点提供所有增删查改服务,备节点不提供任何服务。但是可以通过设置使备节点提供查询服务,这样就可以减少主节点的压力,当客户端进行数据查询时,请求自动转到备节点上。这个设置叫做Read Preference Modes,同时Java客户端提供了简单的配置方式,可以不必直接对数据库进行操作。

       仲裁节点是一种特殊的节点,它本身并不存储数据,主要的作用是决定哪一个备节点在主节点挂掉之后提升为主节点,所以客户端不需要连接此节点。这里虽然只有一个备节点,但是仍然需要一个仲裁节点来提升备节点级别。我开始也不相信必须要有仲裁节点,但是自己也试过没仲裁节点的话,主节点挂了备节点还是备节点,所以咱们还是需要它的。

介绍完了集群方案,那么现在就开始搭建了。

 

1.建立数据文件夹

一般情况下不会把数据目录建立在mongodb的解压目录下,不过这里方便起见,就建在mongodb解压目录下吧。

 

[plain] view plaincopy

 

  1. mkdir -p /mongodb/data/master   
  2. mkdir -p /mongodb/data/slaver   
  3. mkdir -p /mongodb/data/arbiter    
  4. #三个目录分别对应主,备,仲裁节点  

 

2.建立配置文件

由于配置比较多,所以我们将配置写到文件里。

 

[plain] view plaincopy

 

  1. #master.conf  
  2. dbpath=/mongodb/data/master  
  3. logpath=/mongodb/log/master.log  
  4. pidfilepath=/mongodb/master.pid  
  5. directoryperdb=true  
  6. logappend=true  
  7. replSet=testrs  
  8. bind_ip=10.10.148.130  
  9. port=27017  
  10. oplogSize=10000  
  11. fork=true  
  12. noprealloc=true  

[plain] view plaincopy

 

  1. #slaver.conf  
  2. dbpath=/mongodb/data/slaver  
  3. logpath=/mongodb/log/slaver.log  
  4. pidfilepath=/mongodb/slaver.pid  
  5. directoryperdb=true  
  6. logappend=true  
  7. replSet=testrs  
  8. bind_ip=10.10.148.131  
  9. port=27017  
  10. oplogSize=10000  
  11. fork=true  
  12. noprealloc=true  

[plain] view plaincopy

 

  1. #arbiter.conf  
  2. dbpath=/mongodb/data/arbiter  
  3. logpath=/mongodb/log/arbiter.log  
  4. pidfilepath=/mongodb/arbiter.pid  
  5. directoryperdb=true  
  6. logappend=true  
  7. replSet=testrs  
  8. bind_ip=10.10.148.132  
  9. port=27017  
  10. oplogSize=10000  
  11. fork=true  
  12. noprealloc=true  

参数解释:

 

dbpath:数据存放目录

logpath:日志存放路径

pidfilepath:进程文件,方便停止mongodb

directoryperdb:为每一个数据库按照数据库名建立文件夹存放

logappend:以追加的方式记录日志

replSet:replica set的名字

bind_ip:mongodb所绑定的ip地址

port:mongodb进程所使用的端口号,默认为27017

oplogSize:mongodb操作日志文件的最大大小。单位为Mb,默认为硬盘剩余空间的5%

fork:以后台方式运行进程

noprealloc:不预先分配存储

 

3.启动mongodb

进入每个mongodb节点的bin目录下

 

[java] view plaincopy

 

  1. ./monood -f master.conf  
  2. ./mongod -f slaver.conf  
  3. ./mongod -f arbiter.conf  

注意配置文件的路径一定要保证正确,可以是相对路径也可以是绝对路径。

 

 

4.配置主,备,仲裁节点

可以通过客户端连接mongodb,也可以直接在三个节点中选择一个连接mongodb。

 

[plain] view plaincopy

 

  1. ./mongo 10.10.148.130:27017   #ip和port是某个节点的地址  
  2. >use admin  
  3. >cfg={ _id:"testrs", members:[ {_id:0,host:'10.10.148.130:27017',priority:2}, {_id:1,host:'10.10.148.131:27017',priority:1},   
  4. {_id:2,host:'10.10.148.132:27017',arbiterOnly:true}] };  
  5. >rs.initiate(cfg)             #使配置生效  

       cfg是可以任意的名字,当然最好不要是mongodb的关键字,conf,config都可以。最外层的_id表示replica set的名字,members里包含的是所有节点的地址以及优先级。优先级最高的即成为主节点,即这里的10.10.148.130:27017。特别注意的是,对于仲裁节点,需要有个特别的配置——arbiterOnly:true。这个千万不能少了,不然主备模式就不能生效。

 

      配置的生效时间根据不同的机器配置会有长有短,配置不错的话基本上十几秒内就能生效,有的配置需要一两分钟。如果生效了,执行rs.status()命令会看到如下信息:

 

[plain] view plaincopy

 

  1. {  
  2.         "set" : "testrs",  
  3.         "date" : ISODate("2013-01-05T02:44:43Z"),  
  4.         "myState" : 1,  
  5.         "members" : [  
  6.                 {  
  7.                         "_id" : 0,  
  8.                         "name" : "10.10.148.130:27017",  
  9.                         "health" : 1,  
  10.                         "state" : 1,  
  11.                         "stateStr" : "PRIMARY",  
  12.                         "uptime" : 200,  
  13.                         "optime" : Timestamp(1357285565000, 1),  
  14.                         "optimeDate" : ISODate("2013-01-04T07:46:05Z"),  
  15.                         "self" : true  
  16.                 },  
  17.                 {  
  18.                         "_id" : 1,  
  19.                         "name" : "10.10.148.131:27017",  
  20.                         "health" : 1,  
  21.                         "state" : 2,  
  22.                         "stateStr" : "SECONDARY",  
  23.                         "uptime" : 200,  
  24.                         "optime" : Timestamp(1357285565000, 1),  
  25.                         "optimeDate" : ISODate("2013-01-04T07:46:05Z"),  
  26.                         "lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),  
  27.                         "pingMs" : 0  
  28.                 },  
  29.                 {  
  30.                         "_id" : 2,  
  31.                         "name" : "10.10.148.132:27017",  
  32.                         "health" : 1,  
  33.                         "state" : 7,  
  34.                         "stateStr" : "ARBITER",  
  35.                         "uptime" : 200,  
  36.                         "lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),  
  37.                         "pingMs" : 0  
  38.                 }  
  39.         ],  
  40.         "ok" : 1  
  41. }  

如果配置正在生效,其中会包含如下信息:

 

 

[plain] view plaincopy

 

  1. "stateStr" : "RECOVERING"  

同时可以查看对应节点的日志,发现正在等待别的节点生效或者正在分配数据文件。

 

       现在基本上已经完成了集群的所有搭建工作。至于测试工作,可以留给大家自己试试。一个是往主节点插入数据,能从备节点查到之前插入的数据(查询备节点可能会遇到某个问题,可以自己去网上查查看)。二是停掉主节点,备节点能变成主节点提供服务。三是恢复主节点,备节点也能恢复其备的角色,而不是继续充当主的角色。二和三都可以通过rs.status()命令实时查看集群的变化。

 

Sharding

和Replica Set类似,都需要一个仲裁节点,但是Sharding还需要配置节点和路由节点。就三种集群搭建方式来说,这种是最复杂的。部署图如下:

1.启动数据节点

 

[plain] view plaincopy

 

  1. ./mongod --fork --dbpath ../data/set1/ --logpath ../log/set1.log --replSet test #192.168.4.43  
  2. ./mongod --fork --dbpath ../data/set2/ --logpath ../log/set2.log --replSet test #192.168.4.44  
  3. ./mongod --fork --dbpath ../data/set3/ --logpath ../log/set3.log --replSet test #192.168.4.45 决策 不存储数据  

2.启动配置节点

 

 

[plain] view plaincopy

 

  1. ./mongod --configsvr --dbpath ../config/set1/ --port 20001 --fork --logpath ../log/conf1.log #192.168.4.30  
  2. ./mongod --configsvr --dbpath ../config/set2/ --port 20002 --fork --logpath ../log/conf2.log #192.168.4.31  

3.启动路由节点

 

 

[plain] view plaincopy

 

  1. ./mongos --configdb 192.168.4.30:20001,192.168.4.31:20002 --port 27017 --fork --logpath ../log/root.log #192.168.4.29  

       这里我们没有用配置文件的方式启动,其中的参数意义大家应该都明白。一般来说一个数据节点对应一个配置节点,仲裁节点则不需要对应的配置节点。注意在启动路由节点时,要将配置节点地址写入到启动命令里。

 

 

4.配置Replica Set

       这里可能会有点奇怪为什么Sharding会需要配置Replica Set。其实想想也能明白,多个节点的数据肯定是相关联的,如果不配一个Replica Set,怎么标识是同一个集群的呢。这也是人家mongodb的规定,咱们还是遵守吧。配置方式和之前所说的一样,定一个cfg,然后初始化配置。

 

[plain] view plaincopy

 

  1. ./mongo 192.168.4.43:27017   #ip和port是某个节点的地址  
  2. >use admin  
  3. >cfg={ _id:"testrs", members:[ {_id:0,host:'192.168.4.43:27017',priority:2}, {_id:1,host:'192.168.4.44:27017',priority:1},   
  4. {_id:2,host:'192.168.4.45:27017',arbiterOnly:true}] };  
  5. >rs.initiate(cfg)             #使配置生效  

 

 

5.配置Sharding

 

[plain] view plaincopy

 

  1. ./mongo 192.168.4.29:27017   #这里必须连接路由节点  
  2. >sh.addShard("test/192.168.4.43:27017") #test表示replica set的名字 当把主节点添加到shard以后,会自动找到set里的主,备,决策节点  
  3. >db.runCommand({enableSharding:"diameter_test"})    #diameter_test is database name  
  4. >db.runCommand( { shardCollection: "diameter_test.dcca_dccr_test",key:{"__avpSessionId":1}})   

       第一个命令很容易理解,第二个命令是对需要进行Sharding的数据库进行配置,第三个命令是对需要进行Sharding的Collection进行配置,这里的dcca_dccr_test即为Collection的名字。另外还有个key,这个是比较关键的东西,对于查询效率会有很大的影响,具体可以查看Shard Key Overview

 

       到这里Sharding也已经搭建完成了,以上只是最简单的搭建方式,其中某些配置仍然使用的是默认配置。如果设置不当,会导致效率异常低下,所以建议大家多看看官方文档再进行默认配置的修改。

 

Master-Slaver

这个是最简答的集群搭建,不过准确说也不能算是集群,只能说是主备。并且官方已经不推荐这种方式,所以在这里只是简单的介绍下吧,搭建方式也相对简单。

 

[plain] view plaincopy

 

  1. ./mongod --master --dbpath /data/masterdb/      #主节点  
  2.   
  3. ./mongod --slave --source <masterip:masterport> --dbpath /data/slavedb/     备节点  

       基本上只要在主节点和备节点上分别执行这两条命令,Master-Slaver就算搭建完成了。我没有试过主节点挂掉后备节点是否能变成主节点,不过既然已经不推荐了,大家就没必要去使用了。

 

 

       以上三种集群搭建方式首选Replica Set,只有真的是大数据,Sharding才能显现威力,毕竟备节点同步数据是需要时间的。Sharding可以将多片数据集中到路由节点上进行一些对比,然后将数据返回给客户端,但是效率还是比较低的说。

       我自己有测试过,不过具体的机器配置已经不记得了。Replica Set的ips在数据达到1400w条时基本能达到1000左右,而Sharding在300w时已经下降到500ips了,两者的单位数据大小大概是10kb。大家在应用的时候还是多多做下性能测试,毕竟不像Redis有benchmark。

       Mongodb现在用的还是比较多的,但是个人觉得配置太多了。。。。我看官网都看了好多天,才把集群搭建的配置和注意要点弄明白。而且用过的人应该知道mongodb吃内存的问题,解决办法只能通过ulimit来控制内存使用量,但是如果控制不好的话,mongodb会挂掉。。。

 

过段时间我会写一篇关于项目里使用mongodb所涉及到的具体业务,各位有兴趣可以关注下。

 

时间: 2024-12-23 18:28:44

Mongodb集群搭建的三种方式的相关文章

MongoDB集群搭建及Sharding的实现思路

http://www.aliyun.com/zixun/aggregation/13461.html">MongoDB集群搭建 MongoDB的复制集群类型: ·主从模式(master/slave) ·副本集模式(replica set) 副本及模式至少3个节点(一主二从),从节点负责复制主节点的oplog到本地并且应用到本地从而实现冗余. (·arbiter:仅参与选举,但不持有任何数据 ·0优先级:可以触发选举,但是不能被选举成为主节点 ·可以使用repiset来定义集群名称) 1.编

mongodb集群搭建 副本集内部机制原理

副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重? Bully算法 mongodb副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点.一个分布式集群架构中一般都有一个所谓的主节点,可以有很多用途,比如缓存机器节点元

Mongodb集群搭建及spring和java连接配置记录

一.基本环境: mongdb3.0.5数据库 spring-data-mongodb-1.7.2.jar mongo-java-driver-3.0.2.jar linux-redhat6.3 tomcat7     二.搭建mongodb副本集: 1.  分别在三台linux系统机上安装mongodb,(为避免和机器上原有的mongodb端口冲突,这里设为57017): 192.168.0.160 192.168.0.211(192.168.0.33上的虚拟机) 192.168.0.213(1

MongoDB高可用集群配置的几种方案

一.高可用集群的解决方案 高可用性即HA(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间,以提高系统和应用的可用性. 计算机系统的高可用在不同的层面上有不同的表现: (1)网络高可用 由于网络存储的快速发展,网络冗余技术被不断提升,提高IT系统的高可用性的关键应用就是网络高可用性,网络高可用性与网络高可靠性是有区别的,网络高可用性是通过匹配冗余的网络设备实现网络设备的冗余,达到高可用的目的. 比如冗余的交换机,冗余的路由器等

搭建高可用的MongoDB集群

MongoDB公司原名10gen,创立于2007年,在2013年收到一笔2.31亿美元的融资后,公司市值评估已增至10亿美元级别,这个高度是知名开源公司Red Hat(创建于1993年)20年的奋斗成果. 高性能.易扩展一直是MongoDB的立足之本,同时规范的文档和接口更让其深受用户喜爱,这一点从分析DB-Engines的得分结果不难看出--仅仅1年时间,MongoDB就完成了第7名到第五名的提升,得分就从124分上升至214分,上升值是第四名PotgreSQL的两倍,同时当下与Postgre

Elasticsearch与MongoDB 数据同步及分布式集群搭建

过River可以与多种数据源Wikipedia, MongoDB, CouchDB, RabbitMQ, RSS, Sofa, JDBC, FileSystem,Dropbox等同步,公司的业务是用 MongoDB,今天测试环境虚拟机上配置了一下Elasticsearch 与 MongoDB的同步,作个大概的过程记录,主要利用richardwilly98 / elasticsearch-river-mongodb.River通过读取mongodb的oplog来同步数据,oplog这个表来使集群中

mongodb 3.4 集群搭建升级版 五台集群

最新版mongodb推荐使用yaml语法来做配置,另外一些旧的配置在最新版本中已经不在生效,所以我们在生产实际搭建mongodb集群的时候做了一些改进.如果大家不熟悉什么是分片.副本集.仲裁者的话请先移步查看上一篇文章:mongodb 3.4 集群搭建:分片+副本集 和前一个版本相比,改动点有: 配置文件采用yaml方式来配置 生产中取消了仲裁者的角色,因为仲裁者也不会存储数据,只是起到选举的作用,线上为了保证数据安全,每份数据都会配置两个副本集,也就是每份数据存储了三份. 优化配置,采用五台集

严澜:搭建高可用的MongoDB集群(二)

http://www.aliyun.com/zixun/aggregation/13461.html">MongoDB公司原名10gen,创立于2007年,在2013年收到一笔2.31亿美元的融资后,公司市值评估已增至10亿美元级别,这个高度是知名开源公司Red Hat(创建于1993年)20年的奋斗成果. 高性能.易扩展一直是MongoDB的立足之本,同时规范的文档和接口更让其深受用户喜爱,这一点从分析DB-Engines的得分结果不难看出--仅仅1年时间,MongoDB就完成了第7名到

搭建高可用的MongoDB集群(上):MongoDB的配置与副本集

传统的关系数据库具有不错的性能及稳定性,同时,久经历史考验,许多优秀的数据库沉淀了下来,比如MySQL.然而随着数据体积的爆发性增长,数据类型的增多,许多传统关系数据库扩展难的特点也爆发了出来,NoSQL数据库也应运而生.然而区别于以往的使用方法,许多NoSQL都有着自己的限制,从而也导致了入门难的问题.这里我们为大家分享上海创行科技技术总监严澜的博文--如何搭建高效的MongoDB集群. 以下为原文 在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写.海量数据高效存储.高可扩