[SERVER-8972] extent layout differences can cause incorrect capped collection replication Created: 13/Mar/13  Updated: 06/Dec/22  Resolved: 14/Sep/18

Status: Closed
Project: Core Server
Component/s: MMAPv1, Replication, Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-4940 capped collection replication dedups ... Closed
related to SERVER-6984 Initial sync can fail, or break futur... Closed
related to SERVER-30256 Expand testing for initial sync in ca... Closed
is related to SERVER-38724 Under rare conditions, updates to cap... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Case:

 Description   

There is a potential problem in cases where the extent layout of capped collections on primary and secondary is not consistent - for example if the total sizes of the collections are allowed to be slightly different. Or if the total extent size on the secondary is the same as on the primary, but the extent sizes and ordering differs. In either case I think there are situations where the capped collection allocation policy for allocating a new record by removing the oldest record(s) can cause a different number of documents to be deleted on a secondary than on a primary in cases where the physical extent layout differs. This could result in data inconsistencies between primary and secondary.

Also, I'm not sure it might be possible for such an inconsistency to trigger subsequent inconsistencies. (For example an upsert applied to the secondary for a doc that was deleted by allocating a new doc might incorrectly insert the doc.)

Also it might make sense to do a complete analysis of replicating capped collections at some point.


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