MongoDB - Defect ID: 403767
collections in local should have a UUID when UUIDs are enabled and featureCompatibilityVersion is 3.6

Info

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.

Top User Comments

milkie commented on Tue, 24 Oct 2017 13:41:53 +0000: 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. kevin.duong commented on Mon, 23 Oct 2017 16:45:09 +0000: 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 xgen-internal-githook commented on Mon, 9 Oct 2017 23:19:57 +0000: Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'} Message: SERVER-30131 Ensure collections on local have UUIDs Branch: master https://github.com/mongodb/mongo/commit/9e8cce334f74d4e70661bcb3921e069c9a0b248b xgen-internal-githook commented on Mon, 9 Oct 2017 18:50:31 +0000: Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'} Message: Revert "SERVER-30131 Ensure collections on local have UUIDs" This reverts commit 84690cb878db1b231c00d3c9fcb0005ca7cb6361. Branch: master https://github.com/mongodb/mongo/commit/9eba349099bdc58f3ad4e55aa2e846d6d0244f41 xgen-internal-githook commented on Mon, 9 Oct 2017 17:31:03 +0000: Author: {'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'} Message: SERVER-30131 Ensure collections on local have UUIDs Branch: master https://github.com/mongodb/mongo/commit/84690cb878db1b231c00d3c9fcb0005ca7cb6361 judah.schvimer commented on Tue, 26 Sep 2017 15:56:09 +0000: 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. spencer commented on Tue, 26 Sep 2017 15:46:04 +0000: 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. maria.vankeulen commented on Mon, 25 Sep 2017 20:52:35 +0000: 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: * _lastOplogEntryFetcherCallbackForBeginTimestamp() * | * _setLocalCollectionUUIDs() * | * +------------------------------+ * | | * | | * V V * _oplogFetcherCallback() _databasesClonerCallback * | | * | | milkie commented on Thu, 7 Sep 2017 17:54:30 +0000: This might actually be fixed by SERVER-30242; investigate.

Steps to Reproduce