[SERVER-31466] CollectionCloner fails when a collection is dropped and re-created between getMores Created: 09/Oct/17  Updated: 27/Oct/23  Resolved: 09/Apr/20

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

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Backlog - Replication Team
Resolution: Gone away Votes: 0
Labels: initialSync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31267 CollectionCloner fails if collection ... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

If a collection is dropped then immediately re-created on the primary while another node is doing an initial sync of that collection, the initial sync will fail with a CursorNotFoundError

This is because when a collection is dropped, we delete the cursors completely, so we don't know why the cursor was killed.

Possible fixes:

Include uuid of collection in cursor objects; check existence of uuid (instead of or in addition to namespace) to return a CollectionDropped error.

Keep killed cursors around for some length of time (or until the cursor is used), marked to say they were killed because the collection was dropped.



 Comments   
Comment by Siyuan Zhou [ 09/Apr/20 ]

Great. Thanks matthew.russotto! Closing this ticket as Gone Away.

Comment by Matthew Russotto [ 09/Apr/20 ]

This should be fixed in 4.4 by the cloner rewrite; we'll try to resume the collection scan if the cursor goes away, and we do the resume by UUID. Also the UUID of the collection is now included in cursor objects.

Comment by Siyuan Zhou [ 09/Apr/20 ]

matthew.russotto, do you think this is solved by rewriting the cloner. If the sync source behavior is still the same, I feel this might still be a problem. However, since it's rare and not a trivial fix. I'd propose "Won't Fix" if you agree.

Generated at Thu Feb 08 04:27:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.