-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
ALL
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
- is related to
-
SERVER-82180 Capped inserts on the primary can have a different natural ordering from secondaries
- Closed