[SERVER-16049] Replicate capped collection deletes explicitly Created: 10/Nov/14  Updated: 06/Feb/24  Resolved: 23/Apr/21

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

Type: New Feature Priority: Major - P3
Reporter: Eric Milkie Assignee: Gregory Wlodarek
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-55156 Move capped collection responsibiliti... Closed
is depended on by SERVER-12293 initial sync of a capped collection c... Backlog
is depended on by SERVER-32827 Initial sync can fail when syncing a ... Backlog
is depended on by SERVER-56230 Check capped collection hashes across... Closed
is depended on by SERVER-63339 Investigate enabling more data consis... Closed
Documented
is documented by DOCS-14375 Investigate changes in SERVER-16049: ... Closed
Problem/Incident
Related
related to SERVER-63813 Allow transactions and snapshot reads... Backlog
related to SERVER-82863 Add support for the new capped collec... In Progress
related to SERVER-21512 Collection::insertDocuments should ha... Closed
related to SERVER-30256 Expand testing for initial sync in ca... Closed
related to SERVER-80423 Make the preImage document always ava... Closed
is related to SERVER-80302 capped_large_docs.js is not resilient... Closed
is related to SERVER-55411 Enable create_capped_collection*.js f... Closed
is related to SERVER-56262 Fix _cappedFirstRecord usage for capp... Closed
is related to SERVER-52892 Perform capped deletes in the same WU... Closed
is related to SERVER-54890 Disable background validation and dbH... Closed
is related to WT-6383 Key consistent checking should allow ... Closed
Backwards Compatibility: Major Change
Sprint: Execution Team 2021-02-08, Execution Team 2021-03-22, Execution Team 2021-04-05, Execution Team 2021-04-19, Execution Team 2021-05-03
Participants:
Case:
Linked BF Score: 178

 Description   

Rather than letting them be implicit in the capped collection logic when you insert documents at the front.



 Comments   
Comment by Githook User [ 23/Apr/21 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-16049 Add 'assumes_unsharded_collection' tag to capped_large_docs.js
Branch: master
https://github.com/mongodb/mongo/commit/23aed21f706f0cf3b2333c6bf5783341099395e3

Comment by Githook User [ 23/Apr/21 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-16049 Replicate capped collection deletes
Branch: master
https://github.com/mongodb/mongo/commit/7b10322687bab4b0b0bba610b69a4dd5ecb99117

Comment by Githook User [ 23/Apr/21 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-16049 TenantOplogApplier does not enforce operation constraints
Branch: master
https://github.com/mongodb/mongo/commit/a385b13ad00b6c7d52e174a1e39161dde3930765

Comment by Daniel Gottlieb (Inactive) [ 04/Nov/20 ]

I reflagged this for scheduling. I believe the only reasons to do implicit deletion for capped collections was due to MMAP (where capped collections were effectively circular buffers).

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