MongoDB 如何保证 oplog 顺序？

MongoDB 复制集里，主备节点间通过 oplog 来同步数据，Priamry 上写入数据时，会记录一条oplog，Secondary 从 Primary 节点拉取 oplog并重放，以保证最终存储相同的数据集。

oplog 主要特性

幂等性，每一条oplog，重放一次或多次，得到的结果是一样的；为实现幂等 mongodb 对很多操作进行来转换，比如将 insert 转换为 upsert、$inc 操作转换为 $set等等。
固定大小（capped collection），oplog 使用固定空间存储，当空间满了时，会自动删除最旧的文档。
oplog 按时间戳排序，并且在所有节点上顺序保持一致

本文主要介绍MongoDBD 如何保证 oplog 有序存储并读取，关于 oplog 扩展阅读

阿里云MongoDB数据库的自适应oplog管理
MongoDB 3.2删除优化策略
MongoDB Secondary同步慢问题分析
MongoDB Secondary同步慢问题分析(续)
MongoDB同步原理解析

并发写 oplog 时，如何加锁?

Primary 上写入文档时，首先对写入的 DB 加写意向锁，再对集合加写意向锁，然后调用底层引擎接口写入文档，对 local 数据库加写意向锁，对oplog.rs集合加写意向锁，写入 oplog。关于MongoDB 多层级意向锁的机制，参考官方文档。

Write1

DBLock("db1", MODE_IX);

CollectionLock("collection1", MODE_IX);

storageEngine.writeDocument(...);

DBLock("local", MODEX_IX);

CollectionLock("oplog.rs", MODEX_IX);

storageEngine.writeOplog(...);

Write2

DBLock("db2", MODE_IX);

CollectionLock("collection2", MODE_IX);

storageEngine.writeDocument(...);

DBLock("local", MODEX_IX);

CollectionLock("oplog.rs", MODEX_IX);

storageEngine.writeOplog(...);

如何保证Primar上oplog 顺序？

基于上述并发策略，在多个写并发的情况下，如何保证 oplog 顺序？

oplog是一个特殊的 capped collection，文档没有_id字段，但包含一个 ts（时间戳字段），所有 oplog 的文档按照 ts 顺序存储。如下是几条 oplog 的例子。

{ "ts" : Timestamp(1472117563, 1), "h" : NumberLong("2379337421696916806"), "v" : 2, "op" : "c", "ns" : "test.$cmd", "o" : { "create" : "sbtest" } }

{ "ts" : Timestamp(1472117563, 2), "h" : NumberLong("-3720974615875977602"), "v" : 2, "op" : "i", "ns" : "test.sbtest", "o" : { "_id" : ObjectId("57bebb3b082625de06020505"), "x" : "xkfjakfjdksakjf" } }

以 wiredtiger 为例，在写入 oplog 文档时，会以 oplog 的 ts 字段作为 key、文档内容作为 value，写入一条 KV 记录，wiredtiger 会保证存储（btree 或 lsm 的方式都能保证）的文档按 key 来排序，这样就解决『文档按 ts 字段顺序存储』的问题。但仍然存在并发乱序的问题，例如：

并发写入多条 oplog时，时间戳分别是ts1、ts2、ts3 （ts1 < ts2 < ts3 ），ts1、ts3先成功了，这时Secondary 拉取到这2条 oplog，然后 ts2才写成功，然后 Secondary 再拉取到ts2，也就是说 Secondary 看到的 oplog 顺序为ts1、ts3、ts2，就会出现 oplog 乱序的问题。

MongoDB（wiredtiger 引擎）的解决方案是通过在读取时进行限制，保证Secondary 节点看到一定是顺序的，具体实现机制如下：

写入 oplog前，会先加锁给 oplog 分配时间戳，并注册到未提交列表里

lock();

ts = getNextOpTime(); // 根据当前时间戳 + 计数器生成

_uncommittedRecordIds.insert(ts);

unlock();

正式写入 oplog，在写完后，将对应的 oplog 从未提交列表里移除

writeOplog(ts, oplogDocument);

lock();

_uncommittedRecordIds.erase(ts);

unlock();

在拉取 oplog 时

if (_uncommittedRecordIds.empty()) {

    // 所有 oplog 都可读

} else {

    // 只能到未提交列表最小值以前的 oplog

}

通过上述规则，最终保证Primary 上 oplog 按 ts 字段存储，并且 Secondary能按序读取所有 oplog。

如何保证 Secondary 上 oplog 顺序与Primary 一致？

Secondary 把 oplog 拉取到本地后，会多线程重放，最后在一个线程里将拉取到的 oplog原样写入本地的 local.oplog.rs集合，这样就保证 Secondary oplog 最终与 Primary 上完全相同。

作者简介

张友东，阿里巴巴技术专家，主要关注分布式存储、Nosql数据库等技术领域，先后参与TFS（淘宝分布式文件系统)、Redis云数据库等项目，目前主要从事MongoDB云数据库的研发工作，致力于让开发者用上最好的MongoDB云服务。

转载自：http://www.mongoing.com/archives/3177