Geek Answers Handbook

MongoDB 3.0 write lock in oplog collection in replica mode

In replica mode, each write operation to any collection in any database is also written to the oplog collection.

Now, when you write several databases in parallel, all these write operations are also written to oplog. My question is: do these write operations need to block oplog? (I use w: 1). If so, it looks like a global lock between all write operations to all different databases, right?

I would be glad to receive any hints of this.

+8
mongodb replication replicaset wiredtiger
source share
2 answers

According to the documentation , during replication, when MongoDB writes to the collection on a primary basis, MongoDB also writes to the primary oplog, which is a special collection in the local database. Therefore, MongoDB must lock the collection database and the local database. Mongod must simultaneously lock both databases in order to maintain database integrity and ensure that write operations, even with replication, are all-or-nothing operations.

This means that simultaneously writing to several databases in parallel with the primary one can lead to global locks between all write operations. This does not apply to the secondary, since MongoDB is not applied sequentially to secondary entries, but instead collects oplog entries in batches and then applies those batches in parallel.

+4
source share

Disclaimer This is all about me, so please do not crucify me if I am wrong. However, please correct me.

Why should they?

Assume true parallelism of the queries used. So, we have two requests arriving at the same time, and we will need to decide which one needs to be inserted into oplog first. The first one taking the lock will write first, right? There is also a problem. Suppose the first request is simple db.collection.update({_id:"foo"},{$set:{"bar":"baz"}}) , while the other request is more complex, and therefore for a proper assessment takes more time. Therefore, to prevent this, the lock had to be taken on arrival and released after recording the idempotent oplog record.

That's where I have to rely on my memory

However, queries are not applied in parallel. Requests are queued and evaluated in order of receipt. The database is blocked by the query application after starting the query optimizer. During this blocking, idempotent oplog requests are written to oplog. Since the databases are not interconnected, and only one query can be applied to the database at any given time, locking in the database is sufficient. At any time, two requests for changing data in one database cannot be applied simultaneously, so why should the lock be set to oplog? Apparently, the lock takes on a local database. However, since the lock is already taken on the data, I see no reason. * ScratchingMyHead *

+3
source share

More articles:


All Articles