mongodb安全集群搭建

Posted 2022-07-21 jxsdbk

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 #这样就可外部访问了

3. 启动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，新的操作就会覆盖就的操作