[SERVER-36224] Oplog entries for updates to system.views do not have UUIDs Created: 20/Jul/18 Updated: 29/Oct/23 Resolved: 27/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Justin Seyster |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | read-only-views | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.0
|
||||||||
| Sprint: | Query 2018-08-27, Query 2018-09-10 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 64 | ||||||||
| Description |
|
I'm not sure what the impact of this could be, but we should be logging the UUID of the collection here: https://github.com/mongodb/mongo/blob/dd803eee22212313c7808ad4de62de51f1fa56f7/src/mongo/db/views/durable_view_catalog.cpp#L152-L160 |
| Comments |
| Comment by William Schultz (Inactive) [ 10/May/19 ] |
|
justin.seyster Was there any reason this change was not backported to 4.0? Unless you have objections, I am going to request a 4.0 backport, since this issue appeared in a BF on the 4.0 branch (BF-12916). |
| Comment by Githook User [ 27/Aug/18 ] |
|
Author: {'name': 'Justin Seyster', 'email': 'justin.seyster@mongodb.com', 'username': 'jseyster'}Message: Previously, Collection::updateDocument expected to get a namespace and |
| Comment by Judah Schvimer [ 27/Jul/18 ] |
|
This causes an invariant failure during secondary oplog application for updates to system.views that don't have a UUID. As part of this ticket, please add an invariant somewhere that all CRUD oplog entries have a UUID on 4.0 and beyond. |
| Comment by Andy Schwerin [ 23/Jul/18 ] |
|
Since system.views isn't sharded, I think you'd only have trouble if system.views got dropped and recreated during an initial sync or refetch-based rollback. I suspect that's hard for a user to cause. |
| Comment by Kyle Suarez [ 23/Jul/18 ] |
|
Okay, throwing this into the Query Team Needs Triage queue. judah.schvimer, we don't know if this omission has any impact though, right? That would help in determining when we're going to schedule this, if at all. |
| Comment by Judah Schvimer [ 23/Jul/18 ] |
|
yes, when we update a document in the 'system.views' collection, we don't log the UUID of 'system.views'. |
| Comment by Kyle Suarez [ 23/Jul/18 ] |
|
If I'm reading this correctly, this code is on the view update path (i.e. collMod on a view). Views don't have UUIDs. judah.schvimer, when you say "logging the UUID of the collection", do you mean the UUID of the system.views collection? |