Mongo实现主从复制与集群，使用Replica Sets实现

最新推荐文章于 2022-06-13 15:36:54 发布

小飞鹤

最新推荐文章于 2022-06-13 15:36:54 发布

阅读量719

点赞数

分类专栏： mongodb

本文链接：https://blog.csdn.net/he90227/article/details/45536285

版权

mongodb 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

1、概述

复制集是一个带有故障转移的主从集群。是从现有的主从模式演变而来，增加了自动故障转移和节点成员自动恢复。

复制集模式中没有固定的主结点，在启动后，多个服务节点间将自动选举产生一个主结点。该主结点被称为primary，一个或多个从结点被称为secondaries。primary结点基本上就是master结点，不同之处在于primary结点在不同时间可能是不同的服务器。如果当前的主结点失效了，复制集中的其余结点将会试图选出一个新的主结点。

复制集模式的好处是，一切自动化。首先，复制集模式本身做了大量的管理工作，自动管理从节点，确保数据不会不一致。其次，主节点挂掉后，会自动判断集群中的服务器并进行故障转移，推举新的主节点。

一个复制集集群支持1-7台服务器，在一个复制集中各个服务器数据保持完全一致。

在一个复制集集群中，各个服务器有以下几种状态：

Primary 主节点，一个复制集有且仅有一台服务器处于Primary状态，只有主节点才对外提供读写服务。如果主节点挂掉，复制集将会投票选出一个备用节点成为新的主节点。

Secondary 备用节点，复制集允许有多台Secondary，每个备用节点的数据与主节点的数据是完全同步的。

Recovering 恢复中，当复制集中某台服务器挂掉或者掉线后数据无法同步，重新恢复服务后从其他成员复制数据，这时就处于恢复过程，数据同步后，该节点又回到备用状态。

Arbiter 仲裁节点，该类节点可以不用单独存在，如果配置为仲裁节点，就主要负责在复本集中监控其他节点状态，投票选出主节点。该节点将不会用于存放数据。如果没有仲裁节点，那么投票工作将由所有节点共同进行。

Down 无效节点，当服务器挂掉或掉线时就会处于该状态。

复制集的从节点读请求，也是在各个Driver层设置slaveOk的值来实现的。

2、示例

同样的在一台机器上实现此功能。

（1）建立集群名字 yy

第一个节点：C盘，端口号：2222

第二个节点：E盘，端口号：3333

第三个节点：F盘，端口号：4444

（2）实例化Replica Sets

打开任意一个mongod节点，登录后执行如下内容（这里登陆C盘）：

 config={
 _id:"yy",
 members:[
 {_id:0,host:"127.0.0.1:2222"},
 {_id:1,host:"127.0.0.1:3333"},
 {_id:3,host:"127.0.0.1:4444",arbiterOnly:true}
 ]}

进行初始化：

调用rs.conf（）查看配置信息

可以看到2222成了主节点，3333成了从节点，4444是仲裁节点：

调用rs.status()查看状态：

调用 rs.isMaster()查看是否是主节点：

登录4444端口查看：

（3）测试

在主库中插入一节点，如下：

但此时在从库中查询报如下错误：

这是正常的现象，对于SECONDARY节点默认是不可读的。因为SECONDARY是不允许读和写的，在写多读少的应用中，使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk，由SECONDARY来分担读的压力，PRIMARY只承担些操作。

解决方法：

第一种：在从节点设置slaveOk（）：

第二种：在主节点设置：

这样就可以查询了。

同样，当主库中删除一条数据时，会同步到从库。

如果把2222端口的服务停掉，则可以看到3333会成为主节点。

此时在3333上调用rs.status（）可以看到了变化：

3333变成了主库。

以上在一台机器上配置了MongoDB的复制集模式

不同机器上实现的主从复制

一、节点类型

standard：常规节点，它存储一份完整的数据副本，参与选举投票，有可能成为primary节点。

passive：存储了完整的数据副本，参与投票，不能成为primary节点。

arbiter：仲裁节点，只参与投票，不接收复制的数据，也不能成为primary节点。

一个repica sets节点数量最好为奇数(odd)。

二、relica sets 集群三节点分布

实验是三个节点：

两个standard节点（这两个节点直接可以互切primary secondary)。

一个arbiter节点，它手中握着一张选票，决定上面两个standard节点中的哪一个可以成为primay。

下面是我试验的节点分布

三、配置步骤

1.启动三个节点

介绍一下涉及到的参数

--dbpath 数据文件路径

--logpath 日志文件路径

--port 端口号，默认是27017.我这里使用的也是这个端口号.

--replSet 复制集的名字，一个replica sets中的每个节点的这个参数都要用一个复制集名字，这里是test.

--replSet test/ 这个后面跟的是其他standard节点的ip和端口

--maxConns 最大连接数

--fork 后台运行

--logappend 日志文件循环使用，如果日志文件已满，那么新日志覆盖最久日志。

启动第一个standard节点（ip:192.168.0.11)

/mongodb/bin/mongod --dbpath=/mongodb/mongodb_date --logpath=/mongodb/mongodb_log/mongod.log --port 27017 --replSet test/192.168.0.12:27017 --maxConns=2000 --fork --logappend

启动第二个standard节点 (ip:192.168.0.12)

/mongodb/bin/mongod --dbpath=/mongodb/mongodb_date --logpath=/mongodb/mongodb_log/mongod.log --port 27017 --replSet test/192.168.0.11:27017 --maxConns=2000 --fork --logappend

启动arbiter节点，也就是仲裁节点 (ip:192.168.0.13)。注意！--replSet test/后面写的是两个standard节点的ip和端口

/mongodb/bin/mongod --dbpath=/mongodb/mongodb_date --logpath=/mongodb/mongodb_log/mongod.log --port 27017 --replSet test/192.168.0.11:27017,192.168.0.12:27017 --fork --logappend

2.很关键的一步，配置完上面，下面开始初始化各个节点。在第二个启动的节点上，运行mongo

config={
"_id" : "test",
"members" : [
{
"_id" : 0,
"host" : "192.168.0.11:27017"
},
{
"_id" : 1,
"host" : "192.168.0.12:27017"
}
]}

3.加入arbiter节点

PRIMARY> rs.addArb("192.16.0.13:27017");

到了这里，这个集群已经配置完成，三个节点的角色已经分配完毕，怎么查看是否正常呢

1.rs.status()通过这个命令，可以查看各个节点的ip、角色已经是否正常

2.rs.stepDown() 这个命令可以强制primary和standard节点角色互换，从而验证是否能够实现failover功能。

注意：添加新节点前，一定要配置好防火墙，开放对应的IP及PORT。

添加普通数据节点

PRIMARY> rs.add("ip:port")

删除节点

PRIMARY> rs.remove("ip:port")

显示当前谁是primay

PRIMARY> rs.isMaster()

将一个普通数据节点修改为passive节点，也就是能同步数据、投票，但是不能成为primay。
除了仲裁节点，其他每个节点都有个优先权，我们可以通过设置优先权来决定谁的成为primay的权重最大。
MongoDB replica sets中通过设置priority的值来决定优先权的大小，这个值的范围是0--100，值越大，优先权越高。
如果值是0，那么不能成为primay。

1.通过rs.conf()命令查看出节点列表