MongoDB Secondary delay high (synchronous lock) Case study

Encounter Problems : 10 o'clock in the evening, the DBA establishes an index of a collection in the database. In the next few minutes, it happens that a colleague visits an app, verifying that the app's account needs to query the account password from a database table. Causes the inability to query, the colleague cannot log on on the app. The problem was then fed back to the operations department.

Background introduction:

MongoDB version 3.0.2

Build indexes and collection and account queries collection the same server, on different library names.

Because mongodb3.0.2 was used, it was previously known that 3.0 was a row-level lock, and the DBA did not add the parameter background:true when building the table index .

Check the reason:

The point at which a colleague cannot sign in to an app happens to be the time period when the library has an index. So the main troubleshooting on the index. Later, the problem was confirmed by reproducing the problem.

secondary pull to a batch of Oplog, from the beginning of the library replay Oplog, there is a special   lock::P arallelbatchwritermode   lock, this lock blocks all read requests. This explains why the app is inaccessible for several minutes after the index is under construction.

After reviewing the information:

• Try to avoid dirty reading, and so on after a batch of Oplog replay, this batch of data to allow users to read.

• As far as possible to ensure the synchronization performance, imagine, if the replay Oplog, the use of ordinary locks, then the Oplog replay needs to be with the normal read and write competition lock resources, if there is a lot of reading on the secondary, then it will inevitably cause the synchronization of standby gradually.

Although the 3.0 version of the read-write lock does not block the database, do not ignore the sync lockLock::ParallelBatchWriterMode的影响。

Solve the problem:

Index the database as idle as possible;

When indexing is under construction, it is best to add background:true.

This article is from the "Meng Sir accumulation" blog, please be sure to keep this source http://mengsir.blog.51cto.com/2992083/1868966

MongoDB Secondary delay high (synchronous lock) Case study