[SERVER-37980] Add a function to the index builds interface to return the build UUID given a namespace and index name and hook it up for listIndexes to use Created: 07/Nov/18  Updated: 29/Oct/23  Resolved: 05/Feb/20

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.3.4

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-39087 move initial sync index creation logi... Closed
is depended on by SERVER-39453 Add initial sync support for simultan... Closed
Related
related to SERVER-47842 [4.4] listIndexes with includeBuildUU... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2019-02-25, Execution Team 2020-02-10
Participants:

 Description   

There may be race conditions to handle between getting the index catalog entries and accessing the index build interface. I'm not sure whether it's important to give a snapshot view of indexes via listIndexes, in which case we can cut corners and simplify.

Questions to be addressed in regards to initial sync: if listIndexes returns cursor results, and we are racily adding builderUUIDs, does this affect what we expect to see in the oplog? Like seeing an oplog entry when we don’t expect one? Does the catalog index info have to be acquired at the same timestamp as the config.system.indexBuilds data?



 Comments   
Comment by Githook User [ 05/Feb/20 ]

Author:

{'username': 'GWlodarek', 'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com'}

Message: SERVER-37980 Add a function to the index builds interface to return the build UUID given a namespace and index name and hook it up for listIndexes to use
Branch: master
https://github.com/mongodb/mongo/commit/b4ba41a4d11da77437188f3f5d66b003e8ecffac

Comment by Eric Milkie [ 20/Feb/19 ]

I believe initial sync, when processing oplog entries, will need to ignore startIndexBuild oplog entries that reference a buildUUID for an index build that is already started. That should solve any races.
Another issue is that an index build could begin and end, and the index dropped, and another index build with the same spec started, prior to the listIndexes command getting around to listing things. This would mean when initial sync starts processing the oplog, it will attempt to build an index that is in conflict with what listIndexes told us. I think in order to solve this, initial sync needs to take note of what index builds need to be started (i.e. whatever listIndexes says is in progress), but it shouldn't actually start the index builds until either initial sync finishes replaying the oplog, or it encounters an abort or commit for that index.

Generated at Thu Feb 08 04:47:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.