[SERVER-25942] listCollections should not validate views if it isn't returning them Created: 01/Sep/16 Updated: 19/Nov/16 Resolved: 22/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 3.3.12 |
| Fix Version/s: | 3.4.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Guo (Inactive) | Assignee: | Samuel Rossi (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | neweng, read-only-views | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Integration 2016-09-19, Integration 2016-10-10 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||
| Description |
|
This came up during an initial sync because it will shutdown due to listCollections failures with an invalid view definition, after exhausting all initial sync attempts.
|
| Comments |
| Comment by Githook User [ 22/Sep/16 ] |
|
Author: {u'name': u'Sam Rossi', u'email': u'sam.rossi@mongodb.com'}Message: |
| Comment by Githook User [ 20/Sep/16 ] |
|
Author: {u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'}Message: Revert " This reverts commit 079836dc8be3c89fb474c6f7c006154a626c6dac. |
| Comment by Githook User [ 20/Sep/16 ] |
|
Author: {u'name': u'Sam Rossi', u'email': u'sam.rossi@mongodb.com'}Message: |
| Comment by James Wahlin [ 02/Sep/16 ] |
|
Our tentative plan to address is to skip loading view definitions (and therefore validating views) when listCollections is called with a 'type' filter of 'collection'. It is side-effect of the current implementation that this is occurring. If we decide that we do want to validate view definitions as part of initial sync, then it should be done explicitly after clone of the system.views collection and against the local copy. |
| Comment by Scott Hernandez (Inactive) [ 02/Sep/16 ] |
|
After a number of attempts (10 by default) the last failure is fatal. |
| Comment by James Wahlin [ 02/Sep/16 ] |
|
What is expected behavior currently for a replica member that exhausts initial sync restart attempts? Do we transition to RECOVERING (and stay there) or fassert? RECOVERING would give you an indication that something is wrong while allowing you to maintain quorum. |
| Comment by Andy Schwerin [ 02/Sep/16 ] |
|
If you cannot initial sync, and you've lost your quorum, you cannot fix your view definitions because you have no primary. If you've lost quorum because the majority of your voters have corruption, you would have to force reconfig your cluster to even let you alter the view definitions. |
| Comment by Kyle Suarez [ 02/Sep/16 ] |
|
Currently, listCollections fails if the ViewCatalog cannot be reloaded due to the presence of invalid views in system.views. geert.bosch mentioned allowing listCollections to succeed in the presence of invalid views, but to complain loudly with a warning. Is there a precedent for this in other commands? (For example, does validate set {ok: 1} if warnings is set?) Is there a particular reason why initial sync should still succeed in the presence of invalid views? Is there a downstream change that requires this? I would rather say that yes, initial sync fails until you remove the invalid views. |
| Comment by Scott Hernandez (Inactive) [ 02/Sep/16 ] |
|
Tess, is this different than |