学习了如何创建副本集,如何使用副本集,认知了其故障转移策略。我们还需从复制的基础原理了解副本集的工作方式。副本集主要依赖于两个基础机制:oplog和“心跳“。oplog让数据的复制成为可能,而“心跳”则监控健康情况并触发故障转移,后续将看到这些机制时如何运作的。你应该已经逐渐开始理解并能预测副本集的行为了,尤其在故障发生的情况下。
1.关于oplog
oplog是MongoDB复制的关键。oplog是一个固定集合,位于每个复制节点的local数据库里,记录了所有对数据的变更。每次客户端向主节点写入数据,就会自动向主节点的oplog里添加一个条目,其中包含了足够的信息来再现数据。一旦写操作被复制到某个从节点上,从节点的oplog,从节点的oplog中也会有一条关于写入的数据。每个oplog条目都是由一个BSON时间戳进行标识的,所有的从节点都使用这个时间戳来追中他们最后应用的条目。
为了更好的理解其原理,我们仔细看看真实的oplog以及其中的记录。连接上主节点后,切换到local数据库。local数据库中保存了所有的副本集元数据和oplog。当然,数据库本身不能被复制。正如其名,local数据库里的数据对本地节点而言是唯一的,因此不该复制。查看local数据库,会发现一个叫oplog.rs的集合,每个副本集都会把oplog保存在这个集合里。如下图所示:
replset.minvalid包含了指定副本集成员的初始同步信息。system.replset保存了副本集配置文档。me和slaves用来实现写关注。startup_log是启动信息。还有replset.election包含了节点的选举信息。我们会将主要的精力集中在oplog上,查询一条前面你插入数据的那个操作相关的op条目。执行:
db.oplog.rs.find({op:"i"})
在主从节点执行的结果相同,如下图: