[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: |
|
||||||||||||||||
| 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 |
| Comments |
| Comment by Gregory Wlodarek [ 21/Jun/21 ] |
|
This is no longer required as capped deletes are replicated ( |
| Comment by Gregory Wlodarek [ 21/Jan/21 ] |
|
After much thought, we've determined that it would be best to proceed directly with 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 |