[SERVER-30131] collections in local should have a UUID when UUIDs are enabled and featureCompatibilityVersion is 3.6 Created: 13/Jul/17 Updated: 30/Oct/23 Resolved: 10/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Maria van Keulen | Assignee: | Maria van Keulen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Storage 2017-10-02, Storage 2017-10-23 | ||||||||
| Participants: | |||||||||
| Description |
|
local.startup_log (as well as other collections in local) does not currently have a UUID on startup if featureCompatibilityVersion is 3.6 because the featureCompatibilityVersion value is populated from its on-disk value after local.startup_log is created. |
| Comments |
| Comment by Eric Milkie [ 24/Oct/17 ] | |||||||||||
|
kevin.duong Maria is out until Thursday, but I don't believe this commit could have caused the regression. The code changes in this commit only affects server startup and initial syncing. | |||||||||||
| Comment by Kevin Duong [ 23/Oct/17 ] | |||||||||||
|
maria.vankeulen It seems this commit might have introduced some kind of regression on Aggregation.Lookup.LocalArray.Pipeline. See the screenshot below: Do you mind taking a quick look? Issue tracked in BF-6893 | |||||||||||
| Comment by Githook User [ 09/Oct/17 ] | |||||||||||
|
Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}Message: | |||||||||||
| Comment by Githook User [ 09/Oct/17 ] | |||||||||||
|
Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}Message: Revert " This reverts commit 84690cb878db1b231c00d3c9fcb0005ca7cb6361. | |||||||||||
| Comment by Githook User [ 09/Oct/17 ] | |||||||||||
|
Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}Message: | |||||||||||
| Comment by Judah Schvimer [ 26/Sep/17 ] | |||||||||||
|
The best place would probably be in InitialSyncer::_rollbackCheckerCheckForRollbackCallback, right before we declare success. That way if it fails we can still retry initial sync. You should be able to use the StorageInterface synchronously to do this. Please add a unittest for it, though this should be far easier since it doesn't affect the expected network messages. | |||||||||||
| Comment by Spencer Brody (Inactive) [ 26/Sep/17 ] | |||||||||||
|
I think an easier solution may be to wait until the very end of initial sync, right before it's about to complete successfully. At that point you must have already cloned admin.system.version, therefore you know locally what your FCV should be. So as the last step of initial sync you can check your local FCV, and if it's 3.6 just go ahead and assign UUIDs to the local collections, no network I/O required. | |||||||||||
| Comment by Maria van Keulen [ 25/Sep/17 ] | |||||||||||
|
The proposed plan to address adding UUIDs to collections in local for replica sets started with no data files follows. We will do this in the InitialSync process. We will call listCollections, find the admin.system.version collection, and check whether it has a UUID. If so, we add UUIDs to all collections in local. The function encapsulating these steps, _setLocalCollectionUUIDs(), will be threaded in the following way in the initial syncer:
| |||||||||||
| Comment by Eric Milkie [ 07/Sep/17 ] | |||||||||||
|
This might actually be fixed by |