MongoDB Concurrency Model Drives Stress Test Approach on Read Replicas

Post date: Mar 10, 2013 11:22:45 AM

MongoDB uses locks for both reading and writing in order to ensure the consistent view of document data and their consistent writes respectively.

Reading, get more operations on cursors, inserting, updating, deleting, index creation and map reduce jobs all make use of locks. When copying databases,performing journalling and authentication operations and while writing data on primary (the oplog in the local database needs to be written too) several database locks are needed.

The type of lock used is a readers-writer lock which allows concurrent reads but only a single exlusive write at a certain time. Writers are preferred, they having precedence when waiting for a lock together with other readers. The granularity of the lock starting with version 2.2 of

MongoDB is at database level for most read and write operations excepting operations enumerated above. Older versions of MongoDB employed a single wide process level lock at mongod process level.

If the mongod process receives a page fault or the mongod process is likely to read documents which do not reside in memory then the read and write operations will yield their locks in order to allow other operations access to documents which are already loaded into memory while mongod loads the documents needed into memory.

The general model is that long running operations will yield their locks in favor of short running operations as follows: Long running write operations yield their locks in order to allow read operations access to documents and long running reads also yield their locks in favor of writes.

Yielding for a page fault is a new facility which appeared in version 2.2. Before performing a read MongoDB predicts if the data desired is already in memory.If this is not the case (a.k.a. data is not in memory) then the read operation will yield its lock in favor of other operations while mongod is loading data into memory. Once data is loaded into memory the lock is re-acquired and the read operation finally completes.

Secondaries collect oplog entries in batches performing writes in batch ensuring at first that all documents needed for the operation are in memory loading them using a read lock and this way allowing other concurrent reads and then uses a thread pool in order to apply batch writes concurrently. While applying write operations according to the oplog, read operations are not allowed on secondaries.

This characteristic drives to the conclusion that a real stress testing on read replicas is effective when heavy replication takes place.