[SERVER-52892] Perform capped deletes in the same WUOW as inserts Created: 16/Nov/20  Updated: 06/Dec/22  Resolved: 21/Jun/21

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

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-16049 Replicate capped collection deletes e... Closed
related to WT-6383 Key consistent checking should allow ... Closed
is related to SERVER-54890 Disable background validation and dbH... Closed
Assigned Teams:
Storage Execution
Sprint: Execution Team 2020-12-28, Execution Team 2021-01-11
Participants:

 Description   

Capped deletes are the only remaining area where MongoDB performs untimestamped writes to replicated collections. This is a very complicated edge case for WiredTiger, and not doing it at all would give us increased confidence in the code while allowing WT to add more correctness assertions (WT-6838).

It is relatively simple to investigate whether we can perform capped deletes in the same WT transaction as inserts without doing all of the work in SERVER-16049



 Comments   
Comment by Gregory Wlodarek [ 21/Jun/21 ]

This is no longer required as capped deletes are replicated (SERVER-16049) starting in v5.0.

Comment by Gregory Wlodarek [ 21/Jan/21 ]

After much thought, we've determined that it would be best to proceed directly with SERVER-16049 for 5.0 and FCV gate the work.

There's another issue with performing capped deletes in the same WUOW as inserts related to rollback. Capped deletes do not get rolled back due to being performed in an un-timestamped side transaction. With this proposal, capped deletes would be rolled back. This fundamentally changes how rollback on capped collections works and would introduce data inconsistencies between different versioned binaries.

Comment by Gregory Wlodarek [ 07/Jan/21 ]

Here's a bit of an update on this ticket.

Today, on rollback for capped collections, any inserts beyond the stable timestamp are undone but any deletes do not come back due to being performed in an un-timestamped side transaction. After the rollback completes, the fast count reflects the state of the collection at the stable timestamp but post capped deletions.

With the proposed change to perform capped deletes in the same WUOW as inserts, then on rollback deletes will be undone. But because the deletes are not explicitly replicated and have no associated oplog entries with them, it's impossible to correct the fast count in a constant manner. A collection scan during the rollback would be required to fix up the fast counts, which is undesirable and could impact performance.

I think the alternative would be to go ahead directly with doing SERVER-16049, to replicated capped collection deletes explicitly. louis.williams is going to check-in with product on this.

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