[SERVER-82752] Writers can skip acquiring resource metadata lock for capped collection in 4.4 and older versions. Created: 03/Nov/23  Updated: 20/Nov/23  Resolved: 14/Nov/23

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

Type: Bug Priority: Major - P3
Reporter: Suganthi Mani Assignee: Alan Zheng
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File HELP-51123.repro    
Issue Links:
Problem/Incident
Related
is related to SERVER-82180 Capped inserts on the primary can hav... Backlog
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

Prior to 4.7.0 (SERVER-48312), the capped writers may skip acquiring the resource metadata lock, allowing concurrent writes to the capped collection.  We require the resource metadata lock to serialize capped writes and maintain consistent natural ordering across the replica set.  Disparity in natural ordering between the primary and secondaries can lead to tailable capped cursors skipping events upon resuming after a failover.

 

In 4.4, the resource metadata lock is acquired only when CollectionImpl::_needCappedLock is true. And, this flag is set to true only when the following conditions are met:
1) supportsDocLocking() - returns global variable mongo::_supportsDocLocking
2) _recordStore->isCapped()
3) _ns.db() != "local"

After a node restart, supportsDocLocking() may erroneously return false, even if the storage engine is WiredTiger. That's because, as part of storage startup recovery procedure, initializeStorageEngine() first  loads the catalog and initialize the collection here using the default value of mongo::_supportsDocLocking ( false ), before initializing mongo::_supportsDocLocking with the correct true value


Generated at Thu Feb 08 06:50:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.