[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:
Depends
Related
is related to SERVER-3964 Dropping an index invalidates all cur... Closed
Operating System: ALL
Steps To Reproduce:

On a big collection foo with lots of records with an 'i' field:

db.foo.ensureIndex( {x:1} );
db.foo.ensureIndex( {i:1}, {background:true} );
(then while the bg index build is running -- )
db.foo.dropIndex("x_1")

The bg index build aborts with:

{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"ok" : 0,
	"errmsg" : "cursor gone during bg index",
	"code" : 43
}

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?

Generated at Thu Feb 08 03:32:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.