[SERVER-27033] Optype "db" not handled correctly by applyOperation_inlock Created: 14/Nov/16  Updated: 06/Dec/22  Resolved: 04/Sep/19

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

Type: Bug Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-27054 Slave can acknowledge write before in... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

{op: "db"} oplog entries are used to declare the presence of a database. However, applyOperation_inlock() begins to parse them as delete oplog entries, and fails because they do not have an _id field.

{op: "db"} oplog entries are used in master-slave replication. This leads to log lines like:

sync: caught user assertion 4 Failed to apply delete due to missing _id: { ns: "test.", op: "db" } while applying op: { ns: "test.", op: "db" }



 Comments   
Comment by Spencer Brody (Inactive) [ 21/Nov/16 ]

We weren't able to successfully reproduce, but so far we've only ever seen this happen once in one of our tests that was relying on incorrect assumptions about how master-slave initial sync works. We've had no reports of this in from the wild, there's no evidence that it actually causes a problem, and as far as we can tell it's most likely existed as long as master-slave replication has. Throwing this into "planned but not scheduled" for now, if we hear of anyone actually encountering this we can consider pulling forward at that time.

Comment by Spencer Brody (Inactive) [ 15/Nov/16 ]

Tess is going to try to make a repro so we can determine if this is a regression or a beginning-of-time bug.

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