关于java:MongoDB高级应用之高可用方案实战4

45次阅读

共计 9492 个字符,预计需要花费 24 分钟才能阅读完成。

1、MongDB 启动与敞开

1.1、命令行启动


./mongod --fork --dbpath=/opt/mongodb/data ----logpath=/opt/mongodb/log/mongodb.log

1.2、配置文件启动


./mongod -f mongodb.cfg
mongoDB 根本配置 /opt/mongodb/mongodb.cfg
dbpath=/opt/mongodb/data
logpath=/opt/mongodb/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27017

环境变量配置


export PATH=/opt/mongodb/bin:$PATH

2、MongoDB 主从搭建

Mongodb 有三种集群形式的搭建:Master-Slaver/Replica Set / Sharding。上面是最简答的集群搭建,不过精确说也不能算是集群,只能说是主备。并且官网曾经不举荐这种形式,所以在这里只是简略的介绍下吧,搭建形式也绝对简略。主机配置 /opt/mongodb/master-slave/master/mongodb.cfg


dbpath=/opt/mongodb/master-slave/master/data
logpath=/opt/mongodb/master-slave/master/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27001
master=true
source=192.168.209.128:27002

从机配置 /opt/mongodb/master-slave/slave/mongodb.cfg


dbpath=/opt/mongodb/master-slave/slave/data
logpath=/opt/mongodb/master-slave/slave/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27002
slave=true
source=192.168.209.128:27001

启动服务


cd /opt/mongodb/master-slave/master/
mongod --config mongodb.cfg #主节点  
cd /opt/mongodb/master-slave/slave/
mongod --config mongodb.cfg #从节点

连贯测试


#客户端连贯主节点
mongo  --host 192.168.209.128 --port 27001
#客户端从节点
mongo  --host 192.168.209.128 --port 27002

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

3、MongoDB 正本集

中文翻译叫做正本集,不过我并不喜爱把英文翻译成中文,总是感觉怪怪的。其实简略来说就是集群当中蕴含了多份数据,保障主节点挂掉了,备节点能持续提供数据服务,提供的前提就是数据须要和主节点统一。如下图:

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

默认设置下,主节点提供所有增删查改服务,备节点不提供任何服务。然而能够通过设置使备节点提供查问服务,这样就能够缩小主节点的压力,当客户端进行数据查问时,申请主动转到备节点上。这个设置叫做 Read Preference Modes,同时 Java 客户端提供了简略的配置形式,能够不用间接对数据库进行操作。
仲裁节点是一种非凡的节点,它自身并不存储数据,次要的作用是决定哪一个备节点在主节点挂掉之后晋升为主节点,所以客户端不须要连贯此节点。这里尽管只有一个备节点,然而依然须要一个仲裁节点来晋升备节点级别。我开始也不置信必须要有仲裁节点,然而本人也试过没仲裁节点的话,主节点挂了备节点还是备节点,所以咱们还是须要它的。
介绍完了集群计划,那么当初就开始搭建了。

3.1. 建设数据文件夹

个别状况下不会把数据目录建设在 mongodb 的解压目录下,不过这里不便起见,就建在 mongodb 解压目录下吧。


#三个目录别离对应主,备,仲裁节点
mkdir -p /opt/mongodb/replset/master  
mkdir -p /opt/mongodb/replset/slaver   
mkdir -p /opt/mongodb/replset/arbiter    

3.2. 建设配置文件

因为配置比拟多,所以咱们将配置写到文件里。


vi /opt/mongodb/replset/master/mongodb.cfg
dbpath=/opt/mongodb/replset/master/data  
logpath=/opt/mongodb/replset/master/logs/mongodb.log  
logappend=true  
replSet=shard002
bind_ip=192.168.209.128  
port=27017  
fork=true  
vi /opt/mongodb/replset/slave/mongodb.cfg
dbpath=/opt/mongodb/replset/slave/data  
logpath=/opt/mongodb/replset/slave/logs/mongodb.log  
logappend=true  
replSet=shard002
bind_ip=192.168.209.129  
port=27017  
fork=true  
vi /opt/mongodb/replset/arbiter/mongodb.cfg
dbpath=/opt/mongodb/replset/arbiter/data  
logpath=/opt/mongodb/replset/arbiter/logs/mongodb.log  
logappend=true  
replSet=shard002
bind_ip=192.168.209.130  
port=27017  
fork=true  

参数解释:

dbpath:数据寄存目录

logpath:日志寄存门路

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

replSet:replica set 的名字

bind_ip:mongodb 所绑定的 ip 地址

port:mongodb 过程所应用的端口号,默认为 27017

fork:当前台形式运行过程

3.3、散发到集群下的其余机器


#将从节点配置发送到 192.168.209.129
scp -r /opt/mongodb/replset/slave root@192.168.209.129:/opt/mongodb/replset
#将仲裁节点配置发送到 192.168.209.130
scp -r /opt/mongodb/replset/arbiter root@192.168.209.130:/opt/mongodb/replset

3.4. 启动 mongodb

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


#登录 192.168.209.128 启动主节点
monood -f /opt/mongodb/replset/master/mongodb.cfg  
#登录 192.168.209.129 启动从节点
mongod -f /opt/mongodb/replset/slave/mongodb.cfg 
#登录 192.168.209.130 启动仲裁节点
mongod -f /opt/mongodb/replset/arbiter/mongodb.cfg

留神配置文件的门路肯定要保障正确,能够是相对路径也能够是绝对路径。

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

能够通过客户端连贯 mongodb,也能够间接在三个节点中抉择一个连贯 mongodb。


#ip 和 port 是某个节点的地址
mongo 192.168.209.128:27017
use admin 
cfg={_id:"shard002",members:[{_id:0,host:'192.168.209.128:27017',priority:9},{_id:1,host:'192.168.209.129:27017',priority:1},{_id:2,host:'192.168.209.130:27017',arbiterOnly:true}]};
#使配置失效
rs.initiate(cfg)

留神:cfg 是相当于设置一个变量,能够是任意的名字,当然最好不要是 mongodb 的关键字,conf,config 都能够。最外层的_id 示意 replica set 的名字,members 里蕴含的是所有节点的地址以及优先级。优先级最高的即成为主节点,即这里的 192.168.209.128:27017。特地留神的是,对于仲裁节点,须要有个特地的配置——arbiterOnly:true。这个千万不能少了,不然主备模式就不能失效。

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


{  
            "set" : "testrs",  
            "date" : ISODate("2013-01-05T02:44:43Z"),  
            "myState" : 1,  
            "members" : [  
                    {  
                            "_id" : 0,  
                            "name" : "192.168.209.128:27004",  
                            "health" : 1,  
                            "state" : 1,  
                            "stateStr" : "PRIMARY",  
                            "uptime" : 200,  
                            "optime" : Timestamp(1357285565000, 1),  
                            "optimeDate" : ISODate("2017-12-22T07:46:05Z"),  
                            "self" : true  
                    },  
                    {  
                            "_id" : 1,  
                            "name" : "192.168.209.128:27003",  
                            "health" : 1,  
                            "state" : 2,  
                            "stateStr" : "SECONDARY",  
                            "uptime" : 200,  
                            "optime" : Timestamp(1357285565000, 1),  
                            "optimeDate" : ISODate("2017-12-22T07:46:05Z"),  
                            "lastHeartbeat" : ISODate("2017-12-22T02:44:42Z"),  
                            "pingMs" : 0  
                    },  
                    {  
                            "_id" : 2,  
                            "name" : "192.168.209.128:27005",  
                            "health" : 1,  
                            "state" : 7,  
                            "stateStr" : "ARBITER",  
                            "uptime" : 200,  
                            "lastHeartbeat" : ISODate("2017-12-22T02:44:42Z"),  
                            "pingMs" : 0  
                    }  
            ],  
            "ok" : 1  
    }
        

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


"stateStr" : "STARTUP"

同时能够查看对应节点的日志,发现正在期待别的节点失效或者正在调配数据文件。

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

4、MongoDB 数据分片

和 Replica Set 相似,都须要一个仲裁节点,然而 Sharding 还须要配置节点和路由节点。就三种集群搭建形式来说,这种是最简单的。

4.1、配置数据节点


mkdir -p /opt/mongodb/shard/replset/replica1/data
mkdir -p /opt/mongodb/shard/replset/replica1/logs
mkdir -p /opt/mongodb/shard/replset/replica2/data
mkdir -p /opt/mongodb/shard/replset/replica2/logs
mkdir -p /opt/mongodb/shard/replset/replica3/data
mkdir -p /opt/mongodb/shard/replset/replica3/logs
vi /opt/mongodb/shard/replset/replica1/mongodb.cfg
dbpath=/opt/mongodb/shard/replset/replica1/data
logpath=/opt/mongodb/shard/replset/replica1/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27001
replSet=shard001
shardsvr=true
vi /opt/mongodb/shard/replset/replica2/mongodb.cfg
dbpath=/opt/mongodb/shard/replset/replica2/data
logpath=/opt/mongodb/shard/replset/replica2/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27002
replSet=shard001
shardsvr=true
vi /opt/mongodb/shard/replset/replica3/mongodb.cfg
dbpath=/opt/mongodb/shard/replset/replica3/data
logpath=/opt/mongodb/shard/replset/replica3/logs/mongodb.log
logappend=true
fork=true
bind_ip=192.168.209.128
port=27003
replSet=shard001
shardsvr=true

4.2、启动数据节点


mongod -f /opt/mongodb/shard/replset/replica1/mongodb.cfg #192.168.209.128:27001
mongod -f /opt/mongodb/shard/replset/replica2/mongodb.cfg #192.168.209.128:27002
mongod -f /opt/mongodb/shard/replset/replica3/mongodb.cfg #192.168.209.128:27003

4.3、使数据节点集群失效


mongo 192.168.209.128:27001   #ip 和 port 是某个节点的地址  
cfg={_id:"shard001",members:[{_id:0,host:'192.168.209.128:27001'},{_id:1,host:'192.168.209.128:27002'},{_id:2,host:'192.168.209.128:27003'}]};
rs.initiate(cfg)  #使配置失效  

4.4、配置 configsvr


mkdir -p /opt/mongodb/shard/configsvr/config1/data
mkdir -p /opt/mongodb/shard/configsvr/config1/logs
mkdir -p /opt/mongodb/shard/configsvr/config2/data
mkdir -p /opt/mongodb/shard/configsvr/config2/logs
mkdir -p /opt/mongodb/shard/configsvr/config3/data
mkdir -p /opt/mongodb/shard/configsvr/config3/logs
/opt/mongodb/shard/configsvr/config1/mongodb.cfg
dbpath=/opt/mongodb/shard/configsvr/config1/data
configsvr=true
port=28001
fork=true
logpath=/opt/mongodb/shard/configsvr/config1/logs/mongodb.log
replSet=configrs
logappend=true
bind_ip=192.168.209.128
/opt/mongodb/shard/configsvr/config2/mongodb.cfg
dbpath=/opt/mongodb/shard/configsvr/config2/data
configsvr=true
port=28002
fork=true
logpath=/opt/mongodb/shard/configsvr/config2/logs/mongodb.log
replSet=configrs
logappend=true
bind_ip=192.168.209.128
/opt/mongodb/shard/configsvr/config3/mongodb.cfg
dbpath=/opt/mongodb/shard/configsvr/config3/data
configsvr=true
port=28003
fork=true
logpath=/opt/mongodb/shard/configsvr/config3/logs/mongodb.log
replSet=configrs
logappend=true
bind_ip=192.168.209.128

4.5、启动 configsvr 节点


mongod -f /opt/mongodb/shard/configsvr/config1/mongodb.cfg #192.168.209.128:28001
mongod -f /opt/mongodb/shard/configsvr/config2/mongodb.cfg #192.168.209.128:28002
mongod -f /opt/mongodb/shard/configsvr/config3/mongodb.cfg #192.168.209.128:28003

4.6、使 configsvr 节点集群失效


mongo 192.168.209.128:28001   #ip 和 port 是某个节点的地址  
use admin  #先切换到 admin
cfg={_id:"configrs",members:[{_id:0,host:'192.168.209.128:28001'},{_id:1,host:'192.168.209.128:28002'},{_id:2,host:'192.168.209.128:28003'}]};
rs.initiate(cfg)  #使配置失效  

配置路由节点


mkdir -p /opt/mongodb/shard/routesvr/logs
#留神: 路由节点没有 data 文件夹
vi /opt/mongodb/shard/routesvr/mongodb.cfg
configdb=configrs/192.168.209.128:28001,192.168.209.128:28002,192.168.209.128:28003
port=30000
fork=true
logpath=/opt/mongodb/shard/routesvr/logs/mongodb.log
logappend=true
bind_ip=192.168.209.128

4.7. 启动路由节点


./mongos -f /opt/mongodb/shard/routesvr/mongodb.cfg #192.168.209.128:30000

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

4.8. 配置 Replica Set

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

4.9. 配置 Sharding


mongo 192.168.209.128:30000   #这里必须连贯路由节点  
sh.addShard("shard001/192.168.209.128:27001");
sh.addShard("shard002/192.168.209.128:27017");
 #shard001、shard002 示意 replica set 的名字 当把主节点增加到 shard 当前,会主动找到 set 里的主,备,决策节点  
use testdb
sh.enableSharding("testdb")    #testdb is database name  
sh.shardCollection("testdb.testcon",{"name":”hashed”})
db.collection.status()

第一个命令很容易了解,第二个命令是对须要进行 Sharding 的数据库进行配置,第三个命令是对须要进行 Sharding 的 Collection 进行配置,这里的 testcon 即为 Collection 的名字。另外还有个 key,这个是比拟要害的货色,对于查问效率会有很大的影响。

 到这里 Sharding 也曾经搭建实现了,以上只是最简略的搭建形式,其中某些配置依然应用的是默认配置。如果设置不当,会导致效率异样低下,所以倡议大家多看看官网文档再进行默认配置的批改。以上三种集群搭建形式首选 Replica Set,只有真的是大数据,Sharding 能力浮现威力,毕竟备节点同步数据是须要工夫的。Sharding 能够将多片数据集中到路由节点上进行一些比照,而后将数据返回给客户端,然而效率还是比拟低的说。

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

关注微信公众号『Tom 弹架构』回复“MongoDB”可获取配套材料。

本文为“Tom 弹架构”原创,转载请注明出处。技术在于分享,我分享我高兴!如果您有任何倡议也可留言评论或私信,您的反对是我保持创作的能源。关注微信公众号『Tom 弹架构』可获取更多技术干货!

原创不易,保持很酷,都看到这里了,小伙伴记得点赞、珍藏、在看,一键三连加关注!如果你感觉内容太干,能够分享转发给敌人滋润滋润!

正文完
 0