MongoDB集群搭建+节点测试+配置详细

来源：互联网发布：淘宝登录优酷会员手机编辑：程序博客网时间：2024/06/03 22:39

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

mongoDB官方已经不建议使用主从模式了，替代方案是采用副本集的模式，点击查看，如图：
mongorep1
那什么是副本集呢？打魔兽世界总说打副本，其实这两个概念差不多一个意思。游戏里的副本是指玩家集中在高峰时间去一个场景打怪，会出现玩家暴多怪物少的情况，游戏开发商为了保证玩家的体验度，就为每一批玩家单独开放一个同样的空间同样的数量的怪物，这一个复制的场景就是一个副本，不管有多少个玩家各自在各自的副本里玩不会互相影响。 mongoDB的副本也是这个，主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，并且解决了上面第一个问题“主节点挂掉了，整个集群内会自动切换”。难怪mongoDB官方推荐使用这种模式。我们来看看mongoDB副本集的架构图：

mongorep2

由图可以看到客户端连接到整个副本集，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一但主节点挂掉，副本节点就会选举一个新的主服务器，这一切对于应用服务器不需要关心。我们看一下主服务器挂掉后的架构：

mongodb故障转移

副本集中的副本节点在主节点挂掉后通过心跳机制检测到后，就会在集群内发起主节点的选举机制，自动选举一位新的主服务器。看起来很牛X的样子，我们赶紧操作部署一下！
官方推荐的副本集机器数量为至少3个，那我们也按照这个数量配置测试。

今天主要来说说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
mkdir -p /mongodb/data/master   
mkdir -p /mongodb/data/slaver   
mkdir -p /mongodb/data/arbiter    
#三个目录分别对应主，备，仲裁节点  

2.建立配置文件

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

[plain] view plaincopy
#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  

[plain] view plaincopy
#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  

[plain] view plaincopy
#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目录下

[java] view plaincopy
./monood -f master.conf  
./mongod -f slaver.conf  
./mongod -f arbiter.conf  

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

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

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

[plain] view plaincopy
./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()命令会看到如下信息：

[plain] view plaincopy
{  
        "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  
}  

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

[plain] view plaincopy
"stateStr" : "RECOVERING"  

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

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

Sharding

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

1.启动数据节点

[plain] view plaincopy
./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.启动配置节点

[plain] view plaincopy
./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.启动路由节点

[plain] view plaincopy
./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
./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

[plain] view plaincopy
./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，这个是比较关键的东西，对于查询效率会有很大的影响，具体可以查看Shard Key Overview

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

Master-Slaver

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

[plain] view plaincopy
./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会挂掉。。。

—————————————————————————————————分割线---------------------------------------------------------------------------------

报的错误：
"errmsg" : "syncThread: 13257 cmdline oplogsize (100) different than existing (14179) see:http://dochub.mongodb.org/core/increase-oplog"
注释掉 oplogSize=100参数

延迟比较optimeDate就行了

7 成功状态
PRIMARY> rs.status();
{
      "set" : "sso-resti",
      "date" : ISODate("2013-05-03T08:40:46Z"),
      "myState" : 1,
      "members" : [
            {
                     "_id" : 0,
                     "name" : "127.0.0.1:37017",
                     "health" : 1,
                     "state" : 1,
                     "stateStr" : "PRIMARY",
                     "optime" : {
                              "t" : 1367567307000,
                              "i" : 1
                     },
                     "optimeDate" : ISODate("2013-05-03T07:48:27Z"),
                     "self" : true
            },
            {
                     "_id" : 1,
                     "name" : "127.0.0.1:37018",
                     "health" : 1,
                     "state" : 2,
                     "stateStr" : "SECONDARY",
                     "uptime" : 1231,
                     "optime" : {
                              "t" : 1367567307000,
                              "i" : 1
                     },
                     "optimeDate" : ISODate("2013-05-03T07:48:27Z"),
                     "lastHeartbeat" : ISODate("2013-05-03T08:40:45Z"),
                     "pingMs" : 0
            },
            {
                     "_id" : 2,
                     "name" : "127.0.0.1:37019",
                     "health" : 1,
                     "state" : 2,
                     "stateStr" : "SECONDARY",
                     "uptime" : 1052,
                     "optime" : {
                              "t" : 1367567307000,
                              "i" : 1
                     },
                     "optimeDate" : ISODate("2013-05-03T07:48:27Z"),
                     "lastHeartbeat" : ISODate("2013-05-03T08:40:44Z"),
                     "pingMs" : 0
            },
            {
                     "_id" : 3,
                     "name" : "127.0.0.1:37020",
                     "health" : 1,
                     "state" : 2,
                     "stateStr" : "SECONDARY",
                     "uptime" : 1062,
                     "optime" : {
                              "t" : 1367567307000,
                              "i" : 1
                     },
                     "optimeDate" : ISODate("2013-05-03T07:48:27Z"),
                     "lastHeartbeat" : ISODate("2013-05-03T08:40:45Z"),
                     "pingMs" : 0
            }
      ],
      "ok" : 1
}

8 insert data and test

PRIMARY> use test;
switched to db test
PRIMARY> db.tim.save({"":1});
PRIMARY> db.tim.save({"a":2});
PRIMARY> db.tim.find();
{ "_id" : ObjectId("51837ab1c77389f37f74792d"), "" : 1 }
{ "_id" : ObjectId("51837ac0c77389f37f74792e"), "a" : 2 }
PRIMARY>

SECONDARY> show collections;
Fri May  3 16:54:09 uncaught exception: error: { "$err" : "not master and slaveok=false", "code" : 13435 }
SECONDARY>
SECONDARY> db.getMongo().setSlaveOk()
not master and slaveok=false
SECONDARY> db.tim.find();
{ "_id" : ObjectId("51837ab1c77389f37f74792d"), "" : 1 }
{ "_id" : ObjectId("51837ac0c77389f37f74792e"), "a" : 2 }
SECONDARY>

primary库和secondary库上数据一致了,OK.

[续补]

以上的例子是没有设立primary与secondary的切换监控服务器arbiter的,补充一个初始化的时候设立arbiter监控的配置,如下:

config = {_id: 'rpl', members: [
      {_id: 0, host: '10.100.10.19:27017'},
      {_id: 1, host: '10.100.10.19:27018'},
  {_id: 2, host: '10.100.10.19:27019', arbiterOnly: true},
]};
rs.initiate(config);
rs.status();

{
      "set" : "rpl",
      "date" : ISODate("2013-08-02T02:57:09Z"),
      "myState" : 1,
      "members" : [
            {
                     "_id" : 0,
                     "name" : "10.100.10.19:27017",
                     "health" : 1,
                     "state" : 2,
                     "stateStr" : "SECONDARY",
                     "uptime" : 66247,
                     "optime" : {
                              "t" : 1375349303000,
                              "i" : 2995
                     },
                     "optimeDate" : ISODate("2013-08-01T09:28:23Z"),
                     "lastHeartbeat" : ISODate("2013-08-02T02:57:08Z"),
                     "pingMs" : 0
            },
            {
                     "_id" : 1,
                     "name" : "10.100.10.19:27018",
                     "health" : 1,
                     "state" : 1,
                     "stateStr" : "PRIMARY",
                     "optime" : {
                              "t" : 1375349303000,
                              "i" : 2995
                     },
                     "optimeDate" : ISODate("2013-08-01T09:28:23Z"),
                     "self" : true
            },
            {
                     "_id" : 2,
                     "name" : "10.100.10.19:27019",
                     "health" : 1,
                     "state" : 7,
                     "stateStr" : "ARBITER",
                     "uptime" : 66247,
                     "optime" : {
                              "t" : 0,
                              "i" : 0
                     },
                     "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
                     "lastHeartbeat" : ISODate("2013-08-02T02:57:08Z"),
                     "pingMs" : 0
            }
      ],
      "ok" : 1
}
PRIMARY>

---------------------------------------------------------------------------------分割线-----------------------------------------------------------------------------------------------

返回值各字段解释：

sharded：是否可分片

ns：命名空间，按照格式[database].[collection]

count：该集合中的对象或文档数

numExtents：连续的数据文件区域总数。

Size：集合中数据的大小【scale值有影响】

storageSize：分配给该集合的文档存储空间，该值不会减少。【scale值有影响】

totalIndexSize：所有索引的总大小。【scale值有影响】

indexSizes：该值表示集合中所有存在的索引。【scale值有影响】

avgObjSize：集合中对象的平均大小。【scale值有影响】

nindexes：集合的索引数，所有集合至少有一个索引在_id字段。

nchunks：集合分块数。

lastExtentSize：最近分配的扩展大小。【scale值有影响】

paddingFactor：插入的时候在每个文档末尾增加的空间。这提供一个很小的额外磁盘空间让文档有些微的增长而不需要移动文档。mongod会自动计算该值

systemFlags：2.2版新特性。反映该集合内部服务选项的标志。如1代表在_id字段有索引。

userFlags：2.2版新特性。用户设置该集合的标志。在2.2版中唯一的用户标志是 usePowerOf2Sizes。如果usePowerOf2Sizes是可用的，userFlags就是1，其余都是0.

查看各复制集情况

各字段解释：

set：复制集名

date：当前的ISO时间

myState：表明当前复制集状态，0~10分别代表

编号状态

0启动，1 阶段（分配配置）

1主

2次要

3还原（初始同步，后回滚，停滞成员）

4严重错误

5启动，2 阶段（分叉线程）

6未知状态（副本集从未连接到成员）

7仲裁程序

8死机

9回滚

10已删除

syncingTo：只会在副节点出现，保存正在同步的实例的地址。

members：保存复制集中的每个成员信息。

name：该成员所在的地址。

health：健康状态，1表明正在运行，0表明不运行。

State：

编号状态

0启动，1 阶段（分配配置）

1主

2次要

3还原（初始同步，后回滚，停滞成员）

4严重错误

5启动，2 阶段（分叉线程）

6未知状态（副本集从未连接到成员）

7仲裁程序

8死机

9回滚

10已删除

stateStr：描述成员状态的字符串。

Uptime：启动至今的秒数。

Optime：包含最近操作日志中该成员应用了的操作信息。

optimeDate：最近该成员访问操作日志的时间。

lastHeartbeat：最近从该成员得到的心跳信息的时间。

pingMs：往返包在远程成员和本地实例的来回时间（毫秒）。

Self：该查看复制集信息文档存储在当前mongod实例，值为true。

数据插入脚本

可直接在mongo下执行下列javascript代码

插入五百万数据

for(var i=0; i<5000000; i++){

db.test.insert({name : ’mongodb_test’ + i,seq : i})

}

插入一千万数据

for(var i=0; i<10000000; i++){

db.test.insert({name : ’mongodb_test’ + i,seq : i})

}

0 0