1、副本集群是什么
MongoDB副本集群,也被称之为复制集群,其实和Redis、MySQL中的主从集群概念类似,只不过叫法上有所差异,就好比MQ中,称之为镜像集群,名词千变万化,理念殊途同归,内在含义都是:一个主节点拥有读写能力,一或多个从节点全量拷贝主节点的数据,对外提供读的能力。
只不过这里要注意:MongoDB副本集群和传统的主从集群不太一样!无论是Redis,还是MySQL,它们只提供主从复制功能,即自动将主节点上写入的新数据,完整的同步给从节点。但它们并不提供故障迁移的功能!好比在Redis中,当主节点出现故障时,往往需要依靠外力来完成主从切换,因此通常会搭建“一主两从三哨兵”的架构,由哨兵来完成故障迁移的功能。
而MongoDB副本集群,则无需任何外力介入,在主节点发生故障的情况下,无需任何外力介入,能自动完成主从切换,从而对外实现真正意义上的7*24h高可用,并且从节点还可以处理读请求,从而保障MongoDB服务的高性能。
总的来说,MongoDB副本集群源自于主从集群,但在主从的基础上做了很大拓展,其中总共有三种节点角色:
- Primary主节点:拥有读写能力,为集群内的副本节点,提供数据拷贝的支持;
- Replicate副本节点:拥有读能力,数据完全拷贝自主节点,即主从概念中的从节点;
- Arbiter仲裁节点:不具备读写能力,用于故障恢复,提供故障检测、选举投票能力。
MongoDB副本集群中,出现了一个新概念:仲裁节点,其实作用等同于哨兵节点,但它并不是副本集群必须存在的节点,因为主节点、副本节点都拥有投票能力,它的存在只是为了维护集群内的平衡,如集群节点为偶数时,可以添加一个仲裁节点,让集群保持奇数特性,确保每轮选举一次就能推出新主,避免多轮无效竞选的现象出现(不了解选举机制的后面会说原理)。
好了,理论暂且说到这里,咱们先来搭建一个副本集群玩一玩,简单的实战一把。
2、副本集群实战
因为目前只是简单学习,这里选择搭建成本最低的“一主、一副本、一仲裁”集群,并且也不采用三台机器构建,而是基于“伪集群”的思想:
- 单机模式:一台机器对外提供服务;
- 集群模式:多台机器对外提供同一服务;
- 伪集群模式:单台机器上启动多个实例,模拟多机器场景对外提供服务。
整个集群的节点关系如下:
其中主节点、副本节点、仲裁节点的端口分别为:27018、27019、27020
。
①为每个节点创建存放数据、配置文件、日志的目录:
mkdir /app/mongodb/data/replication-cluster &&
mkdir /app/mongodb/log/replication-cluster &&
mkdir /app/mongodb/conf/replication-cluster &&
mkdir /app/mongodb/data/replication-cluster/27018 &&
mkdir /app/mongodb/data/replication-cluster/27019 &&
mkdir /app/mongodb/data/replication-cluster/27020 &&
mkdir /app/mongodb/log/replication-cluster/27018 &&
mkdir /app/mongodb/log/replication-cluster/27019 &&
mkdir /app/mongodb/log/replication-cluster/27020
②编写主节点的配置文件:
vi /app/mongodb/conf/replication-cluster/27018.conf
MongoDB日志存储相关配置
systemLog:
# 将所有日志写到指定文件中
destination: file
# 记录所有日志信息的文件路径
path: "/app/mongodb/log/replication-cluster/27018/mongo.log"
# 当服务重启时,将新日志以追加形式写到现有日志尾部
logAppend: true
storage:
# 指定MongoDB存储数据的目录
dbPath: "/app/mongodb/data/replication-cluster/27018"
processManagement:
# 以后台进程方式运行MongoDB服务
fork: true
# 指定保存mongo进程ID的文件位置
pidFilePath: "/app/mongodb/conf/replication-cluster/27018.pid"
net:
# 绑定服务实例的IP,默认是localhost,这里换成本机IP
bindIp: 192.168.43.5
#绑定的端口,默认是27017
port: 27018
replication:
# 指定副本集群的名称
replSetName: panda
将上述配置信息复制、并根据自己的环境修改后,接着按下esc,输入:wq保存并退出。
③启动主节点服务(依旧使用之前bin目录下的文件,只是换掉配置文件即可):
/app/mongodb/bin/mongod -f /app/mongodb/conf/replication-cluster/27018.conf
④编写副本(从)节点的配置文件,由于和主节点的配置完全相同,因此直接copy一份,接着将相关目录、端口,批量替换成规划中的27019即可:
cd /app/mongodb/conf/replication-cluster/
cp 27018.conf 27019.conf
vi /app/mongodb/conf/replication-cluster/27019.conf
接着不要按insert键,直接输入:%s/27018/27019/g,完成批量替换(记得保存再退出)。
⑤启动副本节点服务:
/app/mongodb/bin/mongod -f /app/mongodb/conf/replication-cluster/27019.conf
⑥编写仲裁节点的配置文件,这里依旧拷贝27018.conf文件进行批量替换:
cp 27018.conf 27020.conf
vi /app/mongodb/conf/replication-cluster/27020.conf
输入:%s/27018/27020/g,完成批量替换,不要忘记保存。
⑦启动仲裁节点服务:
/app/mongodb/bin/mongod -f /app/mongodb/conf/replication-cluster/27020.conf
⑧通过mongosh客户端工具,连接27018主节点,初始化副本集群:
/app/mongodb/bin/mongosh 192.168.43.5:27018
rs.initiate();
执行上述初始化命令,只要看到ok:1这个字段值,说明初始化成功,接着稍等片刻,MongoDB会自动将当前连接的节点,设置为集群的主节点。
⑨通过初始化的主节点,将其他节点加入到集群中,命令如下:
rs.add(host, arbiterOnly);
该方法有两个参数,前者是其他节点的IP:port
,后者则是仅仲裁权力(可选参数),如果置为true
,当前添加的节点则只有选举权力;如果为false
,则拥有数据复制、选举的权力。
添加仲裁节点还有另外一个专门的方法,如下:
rs.addArb(host);
通过该方法添加的仲裁节点,只会拥有选举权力,并不参与副本集群中的数据维护工作。
通过上面的方法,将副本节点加入到集群中:
rs.add("192.168.43.5:27019");
上面添加副本节点没问题,当大家添加仲裁节点之前,需要更改一下默认的“写关注”级别,否则会报如下错误:
MongoServerError: Reconfig attempted to install a config that would change the
implicit default write concern. Use the setDefaultRWConcern command to set
a cluster-wide write concern and try the reconfig again.
这是因为MongoDB5.x
以上的版本,集群内的写关注级别(数据同步模式),会根据节点数量而发生变化,当集群内添加新节点时,就会重新配置“写关注级别”,而仲裁节点并不参与数据同步,添加时就会出毛病,这时需要手动设置一下写关注级别:
db.adminCommand({
"setDefaultRWConcern" : 1,
"defaultWriteConcern" : {
"w" : "majority"
}
});
执行上述命令后,再执行添加仲裁节点的命令,
panda [direct: primary] test> rs.addArb("192.168.43.5:27020");
添加完成后,可以通过下述两个命令查看集群的节点配置、状态:
rs.conf();
rs.status();
其实所有副本集群相关的信息,都保存在local
库的system.replset
集合中,可以直接去查询这个集合。至此,副本集群的环境就搭建完毕,接着来看看节点之间的数据同步效果。
3、副本集群数据同步
①在主节点上进行读写数据测试:
panda [direct: primary] test> use panda;
panda [direct: primary] panda> db.test.insert({_id:1});
panda [direct: primary] panda> db.test.find({_id:1});
此时主节点没有任何异样,读写数据操作都能正常执行。
②新开另一个shell窗口,连接副本节点进行读写数据测试:
/app/mongodb/bin/mongosh 192.168.43.5:27019
panda [direct: secondary] test> use panda;
panda [direct: secondary] panda> db.test.find({_id:1});
报错MongoServerError: not primary and secondaryOk=false .....
此时执行数据读取命令时,又会出现新的报错,说咱们没有权限读取数据,这里需要开启一下权限:
panda [direct: secondary] test> rs.secondaryOk();
如果是4.0以下
的版本,则是rs.slaveOk()
方法,执行该方法后,再执行find
就能正常读取数据。不过需要注意,该方法只针对当前shell有效,当重启shell或打开新的shell会话,需要再次执行该方法来允许读操作。
接着再重新执行读取命令,这时会发现,从节点会将主节点上写入的数据,自动同步过来:
panda [direct: secondary] panda> db.test.find({_id:1});
[ { _id: 1 } ]
同时,在副本节点上执行写操作时,会出现相关报错,提示当前并非主节点,不允许写入数据:
panda [direct: secondary] panda> db.test.insert({_id:2});
报错MongoBulkWriteError: not primary
③再来连接仲裁节点看看情况:
/soft/mongodb/bin/mongosh 192.168.229.135:27020
panda [direct: secondary] test> rs.secondaryOk();
panda [direct: secondary] test> use zhuzi;
panda [direct: secondary] panda> db.test.find({_id:1});
在仲裁节点上执行任何读写操作时,都会出现这个错误:
MongoServerError: node is not in primary or recovering state
提示当前节点,既不是主节点,也不是从节点,所以无法执行相应命令。
④到这里关于数据同步就操作完毕了,不过为了后续外部可以连接,可以顺便开放一下端口:
firewall-cmd --zone=public --add-port=27018/tcp --permanent
firewall-cmd --zone=public --add-port=27019/tcp --permanent
firewall-cmd --zone=public --add-port=27020/tcp --permanent
firewall-cmd --reload
下面来看看MongoDB副本集群中的故障自动切主功能。
4、副本集群主从切换
①先通过ps命令查询所有mongodb的进程:
ps aux | grep mongodb
②通过kill命令强杀27018主节点,模拟主节点宕机下线:
kill -9 42969
③大概等待几秒钟左右,再去27019节点(原本的从)查看集群状态:
rs.status();
此时会发现,没有任何外力介入,副本集群自动完成了主从切换!
④再次重启27018节点(旧主),观察集群的变化:
/app/mongodb/bin/mongod -f /app/mongodb/conf/replication-cluster/27018.conf
结果很显然,虽然“旧主复燃”,但它却没有夺回“老大”的身份,而是变成了“新主”的从节点。
⑤将27018、27019节点,即主、从节点都干掉,再在仲裁节点上观察集群的状态:
kill -9 43032 47881
主、从节点已经失去心跳,整个集群处于不可工作状态,因为仲裁节点上没有数据,无法继续对外提供服务。