[SERVER-33644] getMissingDoc in initial sync needs to be resilient to NamespaceNotFound Created: 02/Mar/18  Updated: 12/Dec/19  Resolved: 12/Dec/19

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Evin Roesle
Resolution: Won't Fix Votes: 2
Labels: former-quick-wins, former-robust-initial-sync, initialSync
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-31264 CollectionCloner should ignore Namesp... Closed
related to SERVER-31339 Behavior difference between count com... Closed
related to SERVER-34110 Ignore NamespaceNotFound errors when ... Closed
is related to SERVER-33617 fix collMod to update by UUID during ... Closed
Participants:
Case:
Linked BF Score: 15

 Description   

When oplog application during initial sync encounters an update to a document it doesn't currently have, it runs getMissingDoc to fetch the document from the sync source. Prior to 3.6, if the getMissingDoc queried a collection that had since been dropped on the sync source, it would return an empty BSONObj, and initial sync would ignore that document, assuming that it had been deleted on the sync source.

In 3.6+, however, we use findOneByUUID to fetch the missing doc, and if you do a query with a UUID and the recipient doesn't know about the UUID, it returns NamespaceNotFound, instead of returning an empty batch like a regular find on a non-existent namespace would.

This can cause initial sync to fail spuriously



 Comments   
Comment by Evin Roesle [ 12/Dec/19 ]

As this resolved on 4.4+, please upgrade to resolve this issue. If you are still experiencing this issue on an older version and are unable to upgrade, please reopen this ticket.

Comment by Judah Schvimer [ 17/Oct/19 ]

This bug went away with SERVER-42022 on 4.4+.

Comment by Spencer Brody (Inactive) [ 02/Mar/18 ]

This is a regression in 3.6 from 3.4

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