[SERVER-82180] Capped inserts on the primary can have a different natural ordering from secondaries Created: 13/Oct/23  Updated: 06/Feb/24

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

Type: Bug Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: former-storex-namer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-82752 Writers can skip acquiring resource m... Closed
related to SERVER-82863 Add support for the new capped collec... In Progress
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

Oplog slots can be reserved for inserts prior to taking an exclusive lock on the metadata resource.

This can generate the following ordering on the primary

Insert 1 Insert 2
Reserve oplog slot with TS(1)  
  Reserve oplog slot with TS(2)
  X-lock resource
  Insert document with RID(1)
X-lock resource  
Insert document with RID(2)  

On the secondary, we apply oplog entries serially for non-clustered capped collections. So we would apply oplog entry TS(1) with RID(1) and oplog entry TS(2) with RID(2) as record IDs are not globally unique. This results in a different natural order between the primary and secondaries, which we guarantee for capped collections.

The same might be possible for updates and deletes.



 Comments   
Comment by Suganthi Mani [ 06/Nov/23 ]

Just a note: I recently filed SERVER-82752 where capped writers may not acquire the collection metadata lock in 4.4 and older versions. This bug can lead to have a natural ordering on primaries different from secondaries. (SERVER-82752 can occur only if it involves node restart).

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