副本集环境的搭建以及一些基本的操作我们都了解了,本文我们来看看这个数据复制到底是怎么实现的。
# 数据同步方式
MongoDB 中的复制功能主要是使用操作日志 oplog.rs 来实现的,oplog.rs 包含了主节点的每一次写操作,oplog.rs 是主节点中 local 数据库的一个固定集合,我们可以通过如下命令查看到:
use local
show tables
如下:
备份节点通过查询这个集合就知道要复制哪些数据,同时,每一个备份节点也都维护着自己的 oplog.rs,自己的 oplog.rs 则用来记录每一次从主节点复制数据的操作,如此,每一个备份节点都可以再作为数据源提供给其他成员使用,如果某一个备份节点在使用的过程中挂掉了,那么当它重启之后,会自动从 oplog.rs 的最后一个操作开始同步。
上文我们也已经说过 oplog.rs 是一个固定集合,我们可以通过 db.getCollection('oplog.rs').stats()
这个命令来查看这个固定集合的属性,包括集合大小等,执行部分结果如下:
{
"ns" : "local.oplog.rs",
"size" : 18170305,
"count" : 177443,
"avgObjSize" : 102,
"storageSize" : 5902336,
"capped" : true,
"max" : -1,
"maxSize" : 1038090240,
"sleepCount" : 0,
"sleepMS" : 0,
}
既然是固定集合,它里边能够保存的数据大小就是有限的。通常,oplog.rs 使用空间的增长速度与系统处理处理写请求的速率近乎相同,比如主节点每分钟处理了 1KB 的写入请求,那么 oplog.rs 也可能会在一分钟内写入 1KB 条操作日志,但是如果主节点执行了批量删除的命令,比如下面这种:
db.c1.deleteMany({x:{$type:1}})
此时每一个受影响的文档都会产生一条 oplog 中的日志,这个时候 oplog.rs 中的日志会快速增加。
# 成员状态
到目前为止我们了解到的成员状态有两种,一个是 PRIMARY ,还有一个是 SECONDDARY ,成员状态的获取需要靠心跳来维护,副本集中的每一个成员每隔两秒就会向其他成员发送一个心跳请求,用来检查成员的状态,成员的状态主要有如下几种:
# STARTUP
副本集中的成员刚刚启动时处于这个状态下,此时,MongoDB 会去加载成员的副本集配置,配置加载成功之后,就进入到 STARTUP2 的状态。
# STARTUP2
整个初始化同步过程都处于这个状态。
# RECOVERING
这个状态是由 STARTUP2 状态来的,此时成员运转正常,但是此时还不能处理读取请求。
# ARBITER
这是仲裁者所处的状态。
# DOWN
当一个原本运行正常的成员无法访问到时,该成员就处于 DOWN 的状态。
# UNKNOWN
如果一个成员无法到达其他任何成员,该成员就处于 UNKNOWN 状态,比如我们利用 rs.add() 方法添加一个不存在的成员,这个成员的状态就是 UNKNOWN。
# REMOVED
成员被从副本集中移除时就变成这个状态。
# ROLLBACK
如果成员正在进行数据回滚,它就处于 ROLLBACK 状态,回滚结束后会转换为 RECOVERING 状态。
# FATAL
当一个成员发生了不可挽回的错误时,且不再尝试恢复正常的话,就处于这个状态。
# 主节点转备份节点
通过如下命令可以让主节点转为备份节点:
rs.stepDown()
主节点转为备份节点之后会有新的主节点被选举出来,可以通过 rs.status() 来查看新的主节点。
# rs.status()方法
前面我们已经多次使用过 rs.status() 方法, rs.status() 方法会列出每个备份节点的含义,我们来看看这些参数的含义,先来列出一个 rs.status() 方法的返回值样例:
{
"members" : [
{
"_id" : 1,
"name" : "192.168.248.135:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 241,
"optime" : {
"ts" : Timestamp(1509881297, 1),
"t" : NumberLong(16)
},
"optimeDurable" : {
"ts" : Timestamp(1509881297, 1),
"t" : NumberLong(16)
},
"optimeDate" : ISODate("2017-11-05T11:28:17Z"),
"optimeDurableDate" : ISODate("2017-11-05T11:28:17Z"),
"lastHeartbeat" : ISODate("2017-11-05T11:28:18.073Z"),
"lastHeartbeatRecv" : ISODate("2017-11-05T11:28:18.769Z"),
"pingMs" : NumberLong(0),
"syncingTo" : "192.168.248.136:27017",
"configVersion" : 15
},
{
"_id" : 3,
"name" : "192.168.248.136:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 250,
"optime" : {
"ts" : Timestamp(1509881297, 1),
"t" : NumberLong(16)
},
"optimeDate" : ISODate("2017-11-05T11:28:17Z"),
"electionTime" : Timestamp(1509881276, 1),
"electionDate" : ISODate("2017-11-05T11:27:56Z"),
"configVersion" : 15,
"self" : true
}
]
}
- stateStr用来描述当前节点的状态。
- uptime表示从成员可达到现在所经历的时间。
- optimeDate表示每个成员的oplog中最后一个操作发生的时间。
- lastHeartbeat表示当前服务器最后一次收到其他成员心跳的时间。
- pingMs表示心跳从当前服务器到达某个成员所花费的平均时间。
- syncingTo表示同步的数据源。
- health表示该服务器是否可达,1表示可达,0表示不可达。
# 复制链问题
数据复制时可以从主节点直接复制,也可以从备份节点开始复制,从备份节点复制可以形成复制链,如果想禁止复制链,即所有的数据都从主节点复制,可以通过 chainingAllowed 属性来设置,具体步骤如下:
config=rs.config()
config.settings.chainingAllowed=false
rs.reconfig(config)
好了,MongoDB 中副本集的其他细节我们就先说到这里,小伙伴们有问题欢迎留言讨论。 参考资料:
- 《MongoDB权威指南第2版》