MongoDB Priamry为何持续出现oplog全表扫描？

最新推荐文章于 2024-07-06 11:40:38 发布

原创最新推荐文章于 2024-07-06 11:40:38 发布 · 1.2k 阅读

CC 4.0 BY-SA版权

文章标签：

线上某 MongoDB 复制集实例（包含 Primary、Secondary、Hidden 3个节点），Primary 节点突然 IOPS 很高，调查后发现，其中 Hidden 处于 RECOVERING 状态，同时 Priamry 上持续有一全表扫描 oplog 的操作，正是这个 oplog 的 COLLSCAN 导致IO很高。

2017-10-23T17:48:01.845+0800 I COMMAND  [conn8766752] query local.oplog.rs query: { ts: { $gte: Timestamp 1505624058000|95, $lte: Timestamp 1505624058000|95 } } planSummary: COLLSCAN cursorid:20808023597 ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:44669401 keyUpdates:0 writeConflicts:0 numYields:353599 nreturned:0 reslen:20 locks:{ Global: { acquireCount: { r: 707200 } }, Database: { acquireount: { r: 353600 }, acquireWaitCount: { r: 15 }, timeAcquiringMicros: { r: 3667 } }, oplog: { acquireCount: { r: 353600 } } } 935646ms

上述问题，初步一看有2个疑问：

Hidden 上最新的 oplog 在 Primary 节点上是存在的，为什么 Hidden 会一直处于 RECOVERING 状态无法恢复？
同步拉取 oplog 时，会走 oplogHack 的路径，即快速根据oplog上次同步的位点定位到指点位置，这里会走一个二分查找，而不是COLLSCAN，然后从这个位点不断的tail oplog。既然有了这个优化，为什么会出现扫描所有的记录？

接下里将结合 MongoDB 同步的细节实现来分析下上述问题产生的原因。

备如何选择同步源？

MongoDB 复制集使用 oplog 来做主备同步，主将操作日志写入 oplog 集合，备从 oplog 集合不断拉取并重放，来保持主备间数据一致。MongoDB 里的 oplog 特殊集合拥有如下特性：

每条 oplog 都包含时间戳，按插入顺序递增，如果底层使用的KV存储引擎，这个时间戳将作为 oplog 在KV引擎里存储的key，可以理解为 oplog 在底层存储就是按时间戳顺序存储的，在底层能快速根据ts找位置。
oplog 集合没有索引，它一般的使用模式是，备根据自己已经同步的时间戳，来定位到一个位置，然后从这个位置不断 tail query oplog。针对这种应用模式，对于 local.oplog.rs.find({ts: {$gte: lastFetechOplogTs}}) 这样的请求，会有特殊的oplogStartHack 的优化，先根据gte的查询条件在底层引擎快速找到起始位置，然后从该位置继续 COLLSCAN。
oplog 是一个 capped collection，即固定大小集合（默认为磁盘大小5%），当集合满了时，会将最老插入的数据删除。

图片描述

选择同步源，条件1：备上最新的oplog时间戳 >= 同步源上最旧的oplog时间戳

备在选择同步源时，会根据 oplog 作为依据，如果自己最新的oplog，比同步源上最老的 oplog 还有旧，比如 `secondaryNewest getRecordStore()->oplogStartHack(txn, goal.getValue()); // 1. 将起始值传到底层引擎，通过二分查找找到起始值对应的RecordId
}

    // Build our collection scan...
    CollectionScanParams params;
    params.collection = collection;
    params.start = *startLoc;                               // 2. 将起始RecordId作为表扫描的参数
    params.direction = CollectionScanParams::FORWARD;
    params.tailable = cq-&gt;getParsed().isTailable();

总结

结合上述分析，当一致时间点对应的oplog在同步源上找不到时，会在同步源上触发一次oplog的全表扫描。当主备之间频繁的切换（比如线上的这个实例因为写入负载调大，主备角色切换过很多次），会导致多次ROLLBACK发生，最后出现备上minvalid里的一致时间点在同步源上找不到，引发了oplog的全表扫描；即使发生全表扫描，因为不包含minvalid的oplog，备也不能选择这个节点当同步源，最后就是一直找不到同步源，处于RECOVERING状态无法恢复，然后不断重试，不断触发主上的oplog全表扫描，恶性循环。

如何避免上述问题？

上述问题一般很难遇到，而且只有oplog集合大的时候影响才会很恶劣。
终极方法还是从代码上修复，我们已经在阿里云MongoDB云数据库里修复这个问题，并会向官方提一个PR，在上述的场景不产生全表扫描，而是返回找不到记录。

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

PS：推荐一个数据库技术线上直播，讲师来自阿里、腾讯、微博、网易等7位一线专家，从核心技术到实践应用，为听众奉上独家数据库深度挖掘指南，欢迎报名参加。

图片描述