[SERVER-66919] Batched TTL deletions can cause out-of-order oplog application for tenant migration state docs and that messes up tenant access blocker entries. Created: 01/Jun/22  Updated: 29/Oct/23  Resolved: 23/Jun/22

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

Type: Bug Priority: Major - P3
Reporter: Suganthi Mani Assignee: Christopher Caplinger
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-66985 Oplog applier should serialize writes... Closed
Related
is related to SERVER-63040 Batch TTL deletions Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Server Serverless 2022-06-13, Server Serverless 2022-06-27
Participants:
Linked BF Score: 131

 Description   

When applying applyOps entries, we execute a code path different from the normal path when applying entries (which, for tenant migration namespaces, will ensure operations are applied serially). As a result, applyOps entries (for example, from a TTL deletion) can be applied in a different thread, thus resulting in out-of-order application. We should ensure that all oplog entries for tenant migration-related namespaces are applied serially.



 Comments   
Comment by Githook User [ 23/Jun/22 ]

Author:

{'name': 'Christopher Caplinger', 'email': 'christopher.caplinger@mongodb.com', 'username': 'UnicodeSnowman'}

Message: SERVER-66919: Serialize all writes to tenant migration namespaces
Branch: davish/SERVER-63099
https://github.com/mongodb/mongo/commit/8d04153c3db149e9f6224e3c2cab31b8d66154fe

Comment by Githook User [ 23/Jun/22 ]

Author:

{'name': 'Christopher Caplinger', 'email': 'christopher.caplinger@mongodb.com', 'username': 'UnicodeSnowman'}

Message: SERVER-66919: Serialize all writes to tenant migration namespaces
Branch: master
https://github.com/mongodb/mongo/commit/8d04153c3db149e9f6224e3c2cab31b8d66154fe

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