MongoDB复制集机制及原理
MongoDB复制集的主要意义在于实现服务高可用。
它的实现依赖于两个方面的功能：
数据写入时将数据迅速复制到另一个独立节点上
在接收写入的节点发生故障时自动选举出一个新的替代节点。
复制集的作用
- 数据分发：将数据从一个区域复制到另一个区域
- 读写分离：读写折分到不同的节点
- 异地灾备：中心节点故障时自动转移到灾备节点
典型复制集结构
- 由3个及以上具有投票权的节点构成
- 一个主节点（PRIMARY）：接受数据写入及进行投票
- 两个及以上从节点（SECONDARY）：复制主节点上新数据及进行投票
- 不推荐使用Arbiter（投票节点）
数据是如何复制的
- 主节点产生数据时（插入、修改、删除等等），向oplog数据集写入变动记录
- 从节点检测主节点oplog数据集，有变动时，读取变动到从节点，然后在从节点复现变动的所有操作。
通过选举完成数据恢复
- 具有投票权的节点两两之间会发送心跳信息，2秒一次
- 5次心跳未收到时，认为节点失联
- 如果失效的是主节点，则从节点会选举出新的主节点
- 如是失效的是从节点，不会发起选举
- 选举是基于RAFT一致性算法实现，大多数投票节点存活的时候，才会发起选举
- 一个集群最多可以有50个节点，但只有7个有投票权的节点
影响选举的因素
- 整个集群必须有大多数的节点存活
-
被选举为主节点的必备条件
- 能够与大多数的节点连通
- 具有较新的oplog
- 具要有较高的优选级（可通过参数配置）
复制节点常见选项
- 投票权（v参数）：有此参数可以参与投票
- 优先级（priority参数）：优先级越高，成为主节点的可能性越高。为0时，永远不会成为主节点。
- 隐藏（hidden参数）：应用不能访问，但可以用来复制数据，可以参与投票，且优先级必须为0，即永远不成为主节点
- 延迟(slaveRelay参数）：单位为秒，控制从主节点复制数据的时间延迟，否则是即时复制。将从节点更改较高延迟，可以在主节点数据删除或更改时，有回退数据的机会。
复制集注意事项
-
硬件
- 无论主从节点，建议采用一样的硬件配置
- 为保证节点不会同时宕机，各节点之间保证硬件的独立
-
软件
- 保证各节点间软件版本一致
- 增加从节点时，不会提升主节点性能，但可以分流读。建议采用分片方式处理性能的问题。
实践
通过在一个电脑上装三个数据库实例来搭建一个复制集，步骤如下：
- 启动一个MongoDB实例；
- 将3个实例搭建成一个复制集
- 对复制集参数的常规调整
创建数据目录
mkdir -p /data/db{1,2,3}配置文件
命名为mongod.conf，每个目录下面一个
每个实例指向不同的端口：28017、28018、28019
systemLog: destination: file path: /data/db1/mongod.log ## 日志文件 logAppend: true storage: dbPath: /data/db1 ## 数据目录 net: bindIp: 0.0.0.0 ## 本机所有网卡连接都提供对外服务 port: 28017 ## 端口号 replication: replSetName: rs0 ## 复制集的名字为 rs0 processManagement: fork: true ## 进程在后台运行
启动MongoDB进程
mongod -f /data/db1/mongod.conf
配置复制集
hostname替换成实际的主机名，需要 /etc/hosts 文件中做了配置
方法1：
mongo --port 28017
> rs.initiate()
> rs.add("HOSTNAME:28018")
> rs.add("HOSTNAME:28019")
方法2：
mongo --port 28017
> rs.initiate({
_id: "rs0",
members: [
{
_id: 0,
host: "localhost:28017"
},
{
_id: 1,
host: "localhost:28018"
},
{
_id: 2,
host: "localhost:28019"
}
]
})
验证配置
在28017上插入数据，然后在28018上查看结果
插入数据
rs0:PRIMARY> db.test.findOne()
rs0:PRIMARY> db.test.insert({a:1})
查找数据
rs0:SECONDARY> rs.slaveOk() ## 使从节点可以读数据 rs0:SECONDARY> db.test.find() rs0:SECONDARY> db.test.find()
