MongoDB高可用复制集架构 [类似于Redis的哨兵模式]

目录

一、MongoDB 复制集

1. 复制集功能

2. 典型复制集结构

3. 数据是如何复制的

4. 通过选举完成故障恢复

5. 影响选举的因素

6. 复制集节点有以下的选配项

7. 复制集注意事项

二、复制集搭建

1. 创建数据目录文件

 2. 准备每个数据库的配置文件

3. 启动三个服务

4. 配置复制集

5. 测试复制集

6. 复制集缺点

7. 使用技巧

---

一、MongoDB 复制集

MongoDB复制集的主要意义在于实现服务高可用，类似于Redis中的哨兵模式。

1. 复制集功能

它主要提供两个方面的功能：

1. 数据写入主节点（Primary）时将数据复制到另一个副本节（Secondary）点上；

2. 主节点发生故障时自动选举出一个新的替代节点

在实现高可用的同时，复制集实现了其他几个作用：

• 数据分发：将数据从一个区域复制到另一个区域，减少另一个区域的读延迟

• 读写分离：不同类型的压力分别在不同的节点上执行

• 异地容灾：在数据中心故障时快速切换到异地

2. 典型复制集结构

一个典型的复制集由三个或三个以上具有投票权的节点组成：

1. 一个主节点（Primary）：接收写入操作，读操作和选举时投票
2. 两个或多个从节点(Secondary)：复制主节点上的新数据和选举时投票

3. 数据是如何复制的

当一个修改操作，无论是插入，更新或删除，到达主节点时，它对数据的操作将被记录下来（经过一些必要的转换），这些记录称为oplog。

从节点通过从主节点上不断获取新进入主节点的oplog，并在自己的数据上回放，以此保持跟主节点的数据一致。

4. 通过选举完成故障恢复

具有投票权的节点之间两两互相发送心跳；

当5次心跳未收到时判断为节点失联

如果失联的是主机点，从节点会发起选举，选出新的主节点

如果失联的是从节点则不会产生新的选举

选举基于RAFT一致性算法实现，选举成功的必要条件是大多数投票节点存活

复制集中最多可以有50个节点，但具有投票权的节点最多7个

5. 影响选举的因素

整个集群必须有大多数节点存活，被选举为主节点的节点必须：

1. 能够与多数节点建立连接
2. 具有较新的oplog
3. 具有较高的优先级（如果有配置）

6. 复制集节点有以下的选配项

• 是否具有投票权（v 参数）： 有则参与投票

• 优先级（priority参数）：优先级越高的节点越优先成为主节点。优先级为0的节点无法成为主节点,默认值为1

• 隐藏（hidden参数）：复制数据，但对应用不可见。隐藏节点可以具有投票权，但优先级必须为0

• 延迟（slaveDelay参数）：复制 n 秒之前的数据，保持与主节点的时间差

• 从节点不建立索引( buildIndexes)

7. 复制集注意事项

硬件：

因为正常的复制集节点都有可能成为主节点，它们的地位是一样的，因此硬件配置上必须一致。

为了保证节点不会同时宕机，各节点的硬件必须具有独立性。

软件：

复制集各节点软件版本必须一致，以避免出现不可预知的问题。

增加节点不会增加系统写性能。

二、复制集搭建

1. 创建数据目录文件

mkdir -p /data/db{1,2,3}

 2. 准备每个数据库的配置文件

复制集的每个mongod进程应该位于不同的服务器。我们现在在一台服务器上运行三个实例，所以要为它们各自配置。

1、不同的端口： 28017， 28018，28019.

2、不同的数据目录

/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-1
/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-2
/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-3

3、同的日志文件路径，实例中使用

/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-1/mongod.log
/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-2/mongod.log
/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-3/mongod.log

4、配置文件

分别创建下面的conf目录和配置文件：

注意：yml配置文件缩进不支持tab键，要用空格！！！

注意：这里绑定的IP是0.0.0.0，真实环境必须绑定内网网卡！！！

/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/conf/mongodb-1.conf

systemLog:
  destination: file
  path: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-1/mongod.log
  logAppend: true
storage:
  dbPath: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-1
net:
  bindIp: 0.0.0.0
  port: 28017
replication:
  replSetName: rs0
processManagement:
  fork: true

/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/conf/mongodb-2.conf

systemLog:
  destination: file
  path: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-2/mongod.log
  logAppend: true
storage:
  dbPath: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-2
net:
  bindIp: 0.0.0.0
  port: 28018
replication:
  replSetName: rs0
processManagement:
  fork: true

/usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/conf/mongodb-3.conf

systemLog:
  destination: file
  path: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-3/mongod.log
  logAppend: true
storage:
  dbPath: /usr/local/mongodb/mongodb-linux-x86_64-rhel70-4.4.2/data/db-3
net:
  bindIp: 0.0.0.0
  port: 28019
replication:
  replSetName: rs0
processManagement:
  fork: true

3. 启动三个服务

mongod -f ./conf/mongodb-1.conf
mongod -f ./conf/mongodb-2.conf
mongod -f ./conf/mongodb-3.conf

 如果是window没法fork， 所以只能用前台进程开启， 需要 开3个命令窗口分别启动。

4. 配置复制集

首先我们连接上客户端：

mongo --host 192.168.131.171 --port 28017

然后开始配置复制集，注意如果有必要，可以将localhost换成自己的服务器IP地址，注意三个服务的端口号要和配置文件中的一致！

rs.initiate({

_id:"rs0",
members:[{
_id:0,
host:"localhost:28017"
},{
_id:1,
host:"localhost:28018"
},{
_id:2,
host:"localhost:28019"
}]
})

注意：

• 默认情况下非主节点不允许读数据
• 可以通过执行 rs.secondaryOk() 开启读权限（需要在从节点上执行这条命令！）

我们现在是在28017上设置复制集，bane28017应当为主节点。虽然刚设置完后显示的是rs0:SECONDARY，之后马上会自动切换成rs0:PRIMARY。

可以查看复制集状态：

sh.status()

 

PRIMARY表示主节点，SECONDARY表示一个副本，也叫复制集。 

5. 测试复制集

成功设置之后，我们接下来来进行测试。

我们首先mongo --host 192.168.131.171 --port 28017 连接到主节点。然后创建一个test数据库，并添加一条文档。

use test

db.users.insertOne({"userName":"xiaoyan", "age":"24"})

然后我们mongo --host 192.168.131.171 --port 28018连接到从节点上去，然后开启读权限：

rs.secondaryOk()

然后我们试着去查询刚才在主节点上设置的数据：

 可以看到，此时从节点上已经同步了我们在主节点上设置的数据了！注意，必须要执行rs.secondaryOk()开启读权限才行！

我们还可以测试自动选举功能。

我们来将刚才的主节点kill掉，然后再登录到某个存活的客户端shell中执行命令：

rs.status()

可以看到，28017这个节点状态已经变成了not reachable。 

而28018却已经变成了新的主节点！

这和Redis的哨兵机制是一样世具备故障转移的能力的。，主节点挂掉之后，剩余的从节点会自动选举出一个新的主节点！！！

而如果一段时间后这个挂掉的节点又恢复了，会自动的加入到数据集中，但是会成为一个从节点。

注意：从节点不提供写功能！ 只提供备份和读数据的能力！

6. 复制集缺点

1、单节点无法承载过多的数据量，和Redis哨兵模式类似

2、如果数据量较大，故障转移会花费较多的恢复时间

3、单点写能力有限

4、维护困难

7. 使用技巧

如果数据量非常大的情况下，可以按照业务创建不同的复制集，比如用户数据集，订单数据集等，通过来将数据打散的方式来减少单节点上的数据量。

如果以上方式不能满足，可以考虑分片集群！类似于Redis的cluster集群模式！请关注下一篇文章！