[SERVER-13626] dropping an index aborts other bg index builds Created: 17/Apr/14 Updated: 13/Aug/15 Resolved: 18/Apr/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Eric Milkie | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | On a big collection foo with lots of records with an 'i' field:
The bg index build aborts with:
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
If you drop one index while another index on the same collection is building in the background, it aborts the background index build. This is because we invalidate all cursors on a collection when we drop an index, not just the cursors affected by the drop. This can affect bg index builds on secondaries, since the concurrent timing of the index build and index drop can be different than on the original primary node. |
| Comments |
| Comment by Eric Milkie [ 18/Apr/14 ] |
|
The code prevents dropIndex from executing if a background index build is in progress, so this problem never crops up. |
| Comment by Eric Milkie [ 17/Apr/14 ] |
|
Plan is to record why an invalidateAll occurred in the Runner, so that an index building Runner can make a decision on what to do based on this value, when recovering from a yield. For collection drops, the index build will abort. For index drops, the index build will continue scanning the records, since it is using an InternalPlanner::CollectionScan plan and these should be unaffected by index drops. |
| Comment by Andy Schwerin [ 17/Apr/14 ] |
|
kamran.khan, could you turn the repro steps here into a jstest-compatible repro script? |