[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: |
|
||||||||
| 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:
|
| 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. |