[SERVER-44820] bgSync grabs DBLock in X mode when reading the oplog Created: 25/Nov/19  Updated: 29/Oct/23  Resolved: 05/Dec/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 4.3.1
Fix Version/s: 4.3.1

Type: Improvement Priority: Major - P3
Reporter: Jason Chan Assignee: Jason Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-39364 Audit uses of setLastOpToSystemLastOp... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-12-16
Participants:

 Description   

Currently, bgsync grabs the database lock in X mode to read the lastAppliedOpTime. We should investigate to see if we can use a global IS lock here which is what we usually do when reading the oplog.



 Comments   
Comment by Githook User [ 05/Dec/19 ]

Author:

{'email': 'jason.chan@mongodb.com', 'name': 'Jason Chan', 'username': 'jasonjhchan'}

Message: SERVER-44820 Remove outer database MODE_X lock when reading the lastAppliedOpTime in bgsync
Branch: master
https://github.com/mongodb/mongo/commit/68ceed74cb9ee4686825d24e41e5d6bb3800334a

Comment by Jason Chan [ 05/Dec/19 ]

Since Helpers::getLast already grabs a collection level lock, it should be safe to remove the outer database lock in MODE_X. We decided to refrain from using the new helper added in SERVER-43656 since it is currently only available through the record store which would require creating a collection object (and grabbing a collection level lock as well). We expect SERVER-39364 to add an interface that will allow us to grab the lastAppliedOpTime while only acquiring a global MODE_IS lock so we can reconsider using the new mechanism here once that is available.

Comment by Daniel Gottlieb (Inactive) [ 26/Nov/19 ]

Not all storage engine's support this (so the existing code can't go away entirely), but SERVER-43656 supports this with a global MODE_IS lock.

Comment by Judah Schvimer [ 25/Nov/19 ]

CC geert.bosch

Generated at Thu Feb 08 05:07:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.