MongoDB Secondary 延时高（同步锁）案例分析

遇到问题：晚10点，DBA在数据库创建了某collection的索引。在以后的几分钟，恰巧有同事访问某应用，验证该应用的帐号需从数据库某表查询帐号密码。致使了没法查询，同事没法登陆上应用。问题便反馈到了运维部。

背景介绍：

    Mongodb版本 3.0.2

    建索引和collection和帐号查询collection所在同一台服务器，不一样库名上。

    因使用的是mongodb3.0.2，以前了解到3.0是行级锁，因而dba在建该表索引时，并未加参数background:true。

查缘由：

    同事没法登陆应用的时间点恰巧是该库有建索引的时间段。因而主要排查在索引上。后来经过复现问题，确认了该问题。

当主库开始建索引时，主库的读写是正常的。应用能够正常访问。但当主库索引创建完成，Secondary 拉取到一批 oplog 后，从库开始重放oplog时，此时就有一个特殊 Lock::ParallelBatchWriterMode 的锁，这个锁会阻塞全部的读请求。 这就解释了为何在建索引以后的 几分钟，应用没法访问。

后查阅了资料：

• 尽可能避免脏读，等一批 oplog 重放完后，这批数据才容许用户读到。

• 尽可能保证同步性能，设想一下，若是重放 oplog 时，使用普通的锁，那么 oplog 的重放就须要跟正常的读写竞争锁资源，若是 Secondary 上有大量的读，那么势必会形成备同步逐步跟不上。

虽然3.0版本的读写锁没有对数据库形成阻塞，但不要忽略同步锁 Lock::ParallelBatchWriterMode的影响。

解决问题：

在数据库尽可能空闲的状态下建索引；

在建索引时，最好仍是加上 background:true。