首页 > 代码库 > MongoDB Secondary 延时高(同步锁)案例分析

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。


本文出自 “濛sir的积累” 博客,请务必保留此出处http://mengsir.blog.51cto.com/2992083/1868966

MongoDB Secondary 延时高(同步锁)案例分析