MongoDB副本集同步原理解析

问题：

1. MongoDB oplog本地写入Primary时如何保证有序；
2. Secondary节点自Primary获取oplog并在本地回放时，如何保证有序；
3. Secondary节点回放oplog在保证有序的前提下，如何保证高效；

---

在MongoDB的副本集中，节点之间是通过oplog来同步数据。Primary节点每执行一次数据写入，都会记录一条oplog，Secondary节点会持续不断的自Primary拉取oplog并在本地回放，从而确保各节点达到数据最终一致性。

Primary节点并发写入数据，时间点分别为t1、t2和t3，按时间先后排序为 t1 -> t2 -> t3；如果t1和t3先落库，t2后落库，那么在oplog集合中如何能保证有序呢？

oplog数据结构：
- ts: 8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。这个值很重要，在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primary
- op：1字节的操作类型
   - "i"： insert
   - "u"： update
   - "d"： delete
   - "c"： db cmd
   - "db"：声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')
   - "n": no op,即空操作，其会定期执行以确保时效性
- ns：操作所在的namespace
- o：操作所对应的document，即当前操作的内容（比如更新操作时要更新的的字段和值）
- o2: 在执行更新操作时的where条件，仅限于update时才有该属性

MongoDB底层通用的存储引擎为WiredTiger、In-Memory，以WiredTiger为例，MongoDB管理层调用WiredTiger引擎接口向oplog集合中插入文档（即记录）；

WiredTiger会以 oplog 的 ts 字段作为 key、文档内容作为 value，写入一条 KV 记录，wiredtiger 会保证存储（btree 或 lsm 的方式都能保证）的文档按 key 来排序，这样就解决“Primary节点oplog如何保证有序”的问题；

---

并发写入多条oplog ts1、ts2、ts3和ts4，其中 ts1

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

1. primary节点在数据写入oplog之前，先加锁给oplog分配时间戳，并注册到未提交列表

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

2. oplog写入成功后，将该oplog对应的时间戳自未提交列表中移除

writeOplog(ts, oplogDocument);
lock();
_uncommittedRecordIds.erase(ts);
unlock();

3. producer thread线程自primary节点获取oplog时

if (_uncommittedRecordIds.empty()) {
    // 所有 oplog 都可读
} else {
    // 只能到未提交列表最小值以前的 oplog
}

如此既可以确保“secondary节点在本地回放oplog时有序”

Secondary节点回放oplog在保证有序的前提下，如何保证高效呢？如下：

---

副本集同步流程图

• producer thread线程将自primary节点获取的oplog存在BgsyncQueue队列中
• replBatcher thread线程通过自BgsyncQueue队列不断获取oplog，并做一个筛选中断，存放在OpQueue队列

满足下述条件中的一个，则中断读取，将存放在OpQueue中的oplog一次性发送给数据回放线程，批量回放：

1. oplog是执行的commands或者索引相关（因为执行commands和索引相关需要锁整个库，所以关于此类oplog单独拿出来回放）
2. OpQueue队列的size大于replBatchLimitBytes [100 MB (64 bit) or 50 MB (32 bit)]
3. OpQueue队列中有数据，并且超过replBatchLimitSeconds时间（1秒）未提交给数据回放线程
4. OpQueue队列中oplog的条数大于replBatchLimitOperations（5000条）

• 数据回放线程将OpQueue中的oplog在secondary节点并发回放，更新数据
• 数据回放结束，通过另外一个总的线程将该部分oplog写入secondary节点的local.oplog.rs集合中，完成本次数据同步工作

如果OpQueue队列中的oplog有对同一个collection的操作，后续并发进行数据回放时，如何保证同一个collections中两条oplog的执行顺序呢？

std::vector>* writerVectors) //申请vector存放每个线程需要回放的oplog信息，每个线程对应一个writerVectors

1. 数据回放之前，将OpQueue队列中的oplog，根据namespace(db.collection)进行hash，hash后的结果为uint32_t（32为无符号整形数字）；
2. 将hash的结果与并发线程数取余得到的结果放到对应编号writerVectors中

如此既可以保证同一个db.collection的oplog被分配到同一个writerVectors中，即同一个线程来回放，可以严格确保oplog的回放顺序

残余问题：

1. oplog集合特别大的时候，secondary节点重启后，producer thread如何保证读取速度？
2. secondary节点回放部分oplog失败，如何rollback？

参考文档：
MongoDB 如何保证 oplog 顺序？
MongoDB复制集同步原理解析