Mongodb集群搭建的三种方式

青旅半醒 2022-07-13 10:26 132阅读 0赞

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

[  
][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**

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

![1358056331_2790.png][]

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

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

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

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

1.建立数据文件夹

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

**\[plain\]** view plain copy

print ?

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

![save_snippets.png][]

mkdir -p /mongodb/data/master  
    
    mkdir -p /mongodb/data/slaver  
    
    mkdir -p /mongodb/data/arbiter

# 三个目录分别对应主，备，仲裁节点 #

2.建立配置文件

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

**\[plain\]** view plain copy

print ?

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

![save_snippets.png][]

#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 plain copy

print ?

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

![save_snippets.png][]

#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 plain copy

print ?

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

![save_snippets.png][]

#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 plain copy

print ?

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

![save_snippets.png][]

./monood -f master.conf
    ./mongod -f slaver.conf
    ./mongod -f arbiter.conf

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

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

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

**\[plain\]** view plain copy

print ?

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)             \#使配置生效

![save_snippets.png][]

./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 plain copy

print ?

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. \}

![save_snippets.png][]

{
            "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 plain copy

print ?

1.  ”stateStr” : “RECOVERING”

![save_snippets.png][]

"stateStr" : "RECOVERING"

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

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

Sharding

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

![1358091861_1772.png][]

1.启动数据节点

**\[plain\]** view plain copy

print ?

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 决策 不存储数据

![save_snippets.png][]

./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 plain copy

print ?

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

![save_snippets.png][]

./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 plain copy

print ?

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

![save_snippets.png][]

./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 plain copy

print ?

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)             \#使配置生效

![save_snippets.png][]

./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 plain copy

print ?

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\}\})

![save_snippets.png][]

./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 plain copy

print ?

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

![save_snippets.png][]

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

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

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

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

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

[MongoDB]: http://lib.csdn.net/base/mongodb
[Link 1]: http://lib.csdn.net/base/mysql
[http_docs.mongodb.org_manual]: http://docs.mongodb.org/manual/
[Java]: http://lib.csdn.net/base/javase
[Linux]: http://lib.csdn.net/base/linux
[1358056331_2790.png]: https://img-my.csdn.net/uploads/201301/13/1358056331_2790.png
[Read Preference Modes]: http://docs.mongodb.org/manual/applications/replication/#read-preference-modes
[save_snippets.png]: /images/20220713/0735de673d1e4ad5a4bafc1d3058f055.png
[Link 2]: http://lib.csdn.net/base/softwaretest
[1358091861_1772.png]: https://img-my.csdn.net/uploads/201301/13/1358091861_1772.png
[Shard Key Overview]: http://docs.mongodb.org/manual/core/sharding/#sharding-shard-key
[Link 3]: http://lib.csdn.net/base/hadoop
[Redis]: http://lib.csdn.net/base/redis