mongodb安全集群搭建

Posted jxsdbk

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mongodb安全集群搭建相关的知识,希望对你有一定的参考价值。

mongo集群搭建

mongodb的集群搭建方式主要有3种,主从模式,Replica set模式, sharding模式,三种模式各有优劣,适用于不同的场景,属Replica set应用最为广泛,主从模式现在用的较少,sharding最为完备,但配置维护较为复杂

mongodb的Replica Set即副本集方式主要有2个目的,一个是数据冗余做故障恢复使用,当发生故障或其他原因造成的宕机时,可以使用副本集进行恢复。另一个是做读写分离,读的请求分流到副本上,减轻主(primary)

的读压力

Replica Set是mongod的实例集合,它们有着同样的数据内容。包含三类角色:

(1)主节点(Primary)

接收所有的写请求,然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点,当Primary挂掉后,其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的,需要转发到Secondary需要客户端修改一下连接配置。

(2)副本节点(Secondary)

与主节点保持同样的数据集。当主节点挂掉的时候,参与选主。

(3)仲裁者(Arbiter) 不保有数据,不参与选主,只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求,Arbiter跑起来几乎没什么大的硬件资源需求,但重要的一点是,在生产环境下它和其他数据节点不要部署在同一台机器上。 注意,一个自动failover的Replica Set节点数必须为奇数,目的是选主投票的时候要有一个大多数才能进行选主决策。 (4)选主过程 其中Secondary宕机,不受影响,若Primary宕机,会进行重新选主

集群配置:

主机

角色

10.0.12.131

主节点

10.0.12.132

从节点

10.0.12.133

仲裁节点

mongo下载地址​​https://www.mongodb.com/download-center/community/releases​

1.下载包配置环境变量

tar zxf mongodb-linux-x86_64-rhel70-4.2.17.tgz /opt/app/mongo

vim /etc/profile

export MONGODB_HOME=/opt/app/mongo export PATH=$PATH:$MONGODB_HOME/bin

2.配置文件

创建目录 mkdir -p /data/mongodb/data,logs/

三台mongo配置文件都是同样的写法

vim  /data/mongodb/mongo.conf


port=27017 #端口
dbpath= /data/mongodb/data/ #数据库存文件存放目录
logpath= /data/mongodb/logs/mongod.log #日志文件存放路径
logappend=true #使用追加的方式写日志
fork=true #不以守护程序的方式启用,即不在后台运行
replSet=sciencedb #Replica Set的名字 集群名称
maxConns=100 #最大同时连接数
noauth=true #不启用验证
#keyFile=/data/test/mongodb/key/keyfile 集群间认证
journal=true #每次写入会记录一条操作日志(通过journal可以重新构造出写入的数据)。
#即使宕机,启动时wiredtiger会先将数据恢复到最近一次的checkpoint点,然后重放后续的journal日志来恢复。
storageEngine=wiredTiger #存储引擎有mmapv1、wiretiger、mongorocks
bind_ip = 10.0.12.131 #这样就可外部访问了


  1. 启动mongodb服务
    3台都要启动
mongod -f  /data/mongodb/mongo.conf

4.在主节点进行配置

mongo 10.0.12.131

cfg= _id:"sciencedb", members:[ _id:0,host:10.0.12.131:27017,priority:2, _id:1,host:10.0.12.132:27017,priority:1, _id:2,host:10.0.12.133:27017,arbiterOnly:true] ;

5.让配置生效

集群cfg配置生效rs.initiate(cfg)

查看是否生效rs.status()

6.添加删除节点

添加节点命令: 添加secondary:rs.add(host: “192.168.255.141:27017”, priority: 1 ) 添加仲裁点:rs.addArb(“192.168.255.142:27017”) 移除节点:rs.remove(host: “192.168.255.141:27017”)

备库是不允许读写的,如果要让备库读写,使用rs.slaveOk();

上面的mongo是不用身份验证进行读写的,现在我们加入认证才能进行读写

我们先创建用户,不然开启了认证没有权限

mongo 10.0.12.131
use admin
db.createUser( user: root, pwd: test123, roles: [ role:"root", db: "admin" ] );

然后关掉mongo

修改mongodb的配置文件
修改成auth=true #启用验证
keyFile=/data/test/mongodb/key/keyfile 注释打开
openssl rand -base64 756 > /data/test/mongodb/key/keyfile 生成加密文件

然后重启mongo服务

我们再登录mongo看下

[root@localhost mongodb]# mongo 10.0.12.131
MongoDB shell version v4.2.17
connecting to: mongodb://10.0.12.131:27017/test?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session "id" : UUID("07dffca9-5c67-48a3-bdd4-93ff465833ca")
MongoDB server version: 4.2.17
sciencedb:PRIMARY> show dbs;
sciencedb:PRIMARY> show dbs;

可以看出,我们查询是没有结果的

现在我们进行验证

sciencedb:SECONDARY> use admin
switched to db admin
sciencedb:SECONDARY> show dbs;
sciencedb:SECONDARY> db.auth("root","test123");
1
sciencedb:PRIMARY> show dbs;
admin 0.000GB
config 0.000GB
local 0.000GB
testdb 0.000GB

可以看出添加认证成功了

细说Primary选举

Primary选举除了在复制集初始化时发生,还有如下场景

复制集被reconfig Secondary节点检测到Primary宕机时,会触发新Primary的选举 当有Primary节点主动stepDown(主动降级为Secondary)时,也会触发新的Primary选举 Primary的选举受节点间心跳、优先级、最新的oplog时间等多种因素影响。

节点间心跳

复制集成员间默认每2s会发送一次心跳信息,如果10s未收到某个节点的心跳,则认为该节点已宕机;如果宕机的节点为Primary,Secondary(前提是可被选为Primary)会发起新的Primary选举。

节点优先级

  • 每个节点都倾向于投票给优先级最高的节点
  • 优先级为0的节点不会主动发起Primary选举
  • 当Primary发现有优先级更高Secondary,并且该Secondary的数据落后在10s内,则Primary会主动降级,让优先级更高的Secondary有成为Primary的机会。

Optime

拥有最新optime(最近一条oplog的时间戳)的节点才能被选为主。

网络分区

只有更大多数投票节点间保持网络连通,才有机会被选Primary;如果Primary与大多数的节点断开连接,Primary会主动降级为Secondary。当发生网络分区时,可能在短时间内出现多个Primary,故Driver在写入时,最好设置『大多数成功』的策略,这样即使出现多个Primary,也只有一个Primary能成功写入大多数。

在MongoDB副本集中,主节点负责处理客户端的读写请求,备份节点则负责映射主节点的数据。

备份节点的工作原理过程可以大致描述为,备份节点定期轮询主节点上的数据操作,然后对自己的数据副本进行这些操作,从而保证跟主节点的数据同步。

至于主节点上的所有数据库状态改变的操作,都会存放在一张特定的系统表中。备份节点则是根据这些数据进行自己的数据更新。

上面提到的数据库状态改变的操作,称为oplog(operation log,主节点操作记录)。oplog存储在local数据库的"oplog.rs"表中。副本集中备份节点异步的从主节点同步oplog,然后重新执行它记录的操作,以此达到了数据同步的作用。

关于oplog有几个注意的地方:

  • oplog只记录改变数据库状态的操作
  • 存储在oplog中的操作并不是和主节点执行的操作完全一样,例如"$inc"操作就会转化为"$set"操作
  • oplog存储在固定集合中(capped collection),当oplog的数量超过oplogSize,新的操作就会覆盖就的操作

以上是关于mongodb安全集群搭建的主要内容,如果未能解决你的问题,请参考以下文章

MongoDB 分片、仲裁器和集群设置

Linux 搭建MongoDB复制集群

初识MongoDB

mongodb安全集群搭建

docker-compose搭建mongoDB副本集(1主+1副+1仲裁)

搭建 MongoDB分片(sharding) / 分区 / 集群环境