2.建立配置文件
由于配置比较多,所以我们将配置写到文件里。
-
#master.conf
-
dbpath=/mongodb/data/master
-
logpath=/mongodb/log/master.log
-
pidfilepath=/mongodb/master.pid
-
directoryperdb=true
-
logappend=true
-
replSet=testrs
-
bind_ip=10.10.148.130
-
port=27017
-
oplogSize=10000
-
fork=true
-
noprealloc=true
-
#slaver.conf
-
dbpath=/mongodb/data/slaver
-
logpath=/mongodb/log/slaver.log
-
pidfilepath=/mongodb/slaver.pid
-
directoryperdb=true
-
logappend=true
-
replSet=testrs
-
bind_ip=10.10.148.131
-
port=27017
-
oplogSize=10000
-
fork=true
-
noprealloc=true
-
#arbiter.conf
-
dbpath=/mongodb/data/arbiter
-
logpath=/mongodb/log/arbiter.log
-
pidfilepath=/mongodb/arbiter.pid
-
directoryperdb=true
-
logappend=true
-
replSet=testrs
-
bind_ip=10.10.148.132
-
port=27017
-
oplogSize=10000
-
fork=true
-
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目录下
-
./monood -f master.conf
-
./mongod -f slaver.conf
-
./mongod -f arbiter.conf
注意配置文件的路径一定要保证正确,可以是相对路径也可以是绝对路径。
4.配置主,备,仲裁节点
可以通过客户端连接mongodb,也可以直接在三个节点中选择一个连接mongodb。
-
./mongo 10.10.148.130:27017 #ip和port是某个节点的地址
-
>use admin
-
>cfg={ _id:"testrs", members:[ {_id:0,host:'10.10.148.130:27017',priority:2}, {_id:1,host:'10.10.148.131:27017',priority:1},
-
{_id:2,host:'10.10.148.132:27017',arbiterOnly:true}] };
-
>rs.initiate(cfg) #使配置生效
cfg是可以任意的名字,当然最好不要是mongodb的关键字,conf,config都可以。最外层的_id表示replica
set的名字,members里包含的是所有节点的地址以及优先级。优先级最高的即成为主节点,即这里的10.10.148.130:27017。特别注
意的是,对于仲裁节点,需要有个特别的配置——arbiterOnly:true。这个千万不能少了,不然主备模式就不能生效。
配置的生效时间根据不同的机器配置会有长有短,配置不错的话基本上十几秒内就能生效,有的配置需要一两分钟。如果生效了,执行rs.status()命令会看到如下信息:
-
{
-
"set" : "testrs",
-
"date" : ISODate("2013-01-05T02:44:43Z"),
-
"myState" : 1,
-
"members" : [
-
{
-
"_id" : 0,
-
"name" : "10.10.148.130:27017",
-
"health" : 1,
-
"state" : 1,
-
"stateStr" : "PRIMARY",
-
"uptime" : 200,
-
"optime" : Timestamp(1357285565000, 1),
-
"optimeDate" : ISODate("2013-01-04T07:46:05Z"),
-
"self" : true
-
},
-
{
-
"_id" : 1,
-
"name" : "10.10.148.131:27017",
-
"health" : 1,
-
"state" : 2,
-
"stateStr" : "SECONDARY",
-
"uptime" : 200,
-
"optime" : Timestamp(1357285565000, 1),
-
"optimeDate" : ISODate("2013-01-04T07:46:05Z"),
-
"lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),
-
"pingMs" : 0
-
},
-
{
-
"_id" : 2,
-
"name" : "10.10.148.132:27017",
-
"health" : 1,
-
"state" : 7,
-
"stateStr" : "ARBITER",
-
"uptime" : 200,
-
"lastHeartbeat" : ISODate("2013-01-05T02:44:42Z"),
-
"pingMs" : 0
-
}
-
],
-
"ok" : 1
-
}
如果配置正在生效,其中会包含如下信息:
-
"stateStr" : "RECOVERING"
同时可以查看对应节点的日志,发现正在等待别的节点生效或者正在分配数据文件。
现在基本上已经完成了集群的所有搭建工作。至于测试工作,可以留给大家自己试试。一个是往主节点插入数据,能从备节点查到之前插入的数据(查询备节点可能
会遇到某个问题,可以自己去网上查查看)。二是停掉主节点,备节点能变成主节点提供服务。三是恢复主节点,备节点也能恢复其备的角色,而不是继续充当主的
角色。二和三都可以通过rs.status()命令实时查看集群的变化。
Sharding
和Replica Set类似,都需要一个仲裁节点,但是Sharding还需要配置节点和路由节点。就三种集群搭建方式来说,这种是最复杂的。部署图如下:
1.启动数据节点
-
./mongod --fork --dbpath ../data/set1/ --logpath ../log/set1.log --replSet test #192.168.4.43
-
./mongod --fork --dbpath ../data/set2/ --logpath ../log/set2.log --replSet test #192.168.4.44
-
./mongod --fork --dbpath ../data/set3/ --logpath ../log/set3.log --replSet test #192.168.4.45 决策 不存储数据
2.启动配置节点
-
./mongod --configsvr --dbpath ../config/set1/ --port 20001 --fork --logpath ../log/conf1.log #192.168.4.30
-
./mongod --configsvr --dbpath ../config/set2/ --port 20002 --fork --logpath ../log/conf2.log #192.168.4.31
3.启动路由节点
-
./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,然后初始化配置。
-
./mongo 192.168.4.43:27017 #ip和port是某个节点的地址
-
>use admin
-
>cfg={ _id:"testrs", members:[ {_id:0,host:'192.168.4.43:27017',priority:2}, {_id:1,host:'192.168.4.44:27017',priority:1},
-
{_id:2,host:'192.168.4.45:27017',arbiterOnly:true}] };
-
>rs.initiate(cfg) #使配置生效
5.配置Sharding
-
./mongo 192.168.4.29:27017 #这里必须连接路由节点
-
>sh.addShard("test/192.168.4.43:27017") #test表示replica set的名字 当把主节点添加到shard以后,会自动找到set里的主,备,决策节点
-
>db.runCommand({enableSharding:"diameter_test"}) #diameter_test is database name
-
>db.runCommand( { shardCollection: "diameter_test.dcca_dccr_test",key:{"__avpSessionId":1}})
第一个命令很容易理解,第二个命令是对需要进行Sharding的数据库进行配置,第三个命令是对需要进行Sharding的Collection进行配
置,这里的dcca_dccr_test即为Collection的名字。另外还有个key,这个是比较关键的东西,对于查询效率会有很大的影响,具体可
以查看
-
./mongod --master --dbpath /data/masterdb/ #主节点
-
-
./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会挂掉。。。