[SERVER-33634] Allow dropDatabase (and dropCollection) to succeed when index build is in progress Created: 02/Mar/18  Updated: 28/Feb/20  Resolved: 09/Mar/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-46122 Make the drop command abort in-progre... Closed
duplicates SERVER-46123 Make the dropDatabase command abort i... Closed
duplicates SERVER-37726 Make dropIndexes abort in-progress in... Closed
Related
is related to PYTHON-2068 Test Failure - test_session.TestSessi... Closed
is related to SERVER-31239 Disable resync command and remove tests Closed
is related to SERVER-32033 Allow dropIndex to succeed when index... Closed
Participants:
Linked BF Score: 7

 Description   

Currently dropping a database while a background index build is in progress fails

> db.dropDatabase()
{
	"ok" : 0,
	"errmsg" : "cannot perform operation: a background operation is currently running for database test",
	"code" : 12586,
	"codeName" : "BackgroundOperationInProgressForDatabase"
}

This also results in initial sync's "dropAllDatabasesExceptLocal" failing. Since we won't be needing the index, we should just cancel the build.



 Comments   
Comment by Shane Harvey [ 28/Feb/20 ]

SERVER-46123 fixes the issue I described.

Comment by Eric Milkie [ 28/Jan/20 ]

Can you file a new ticket for this? And mention what the expected behavior is — I thought what you described was the current behavior in 4.2 but I could be mistaken.

Comment by Shane Harvey [ 27/Jan/20 ]

Starting in 4.3, a background operation such as an ongoing createIndex will cause a subsequent dropDatabase to fail with:

{
	"ok" : 0,
	"errmsg" : "cannot perform operation: a background operation is currently running for database pymongo_test",
	"code" : 12586,
	"codeName" : "BackgroundOperationInProgressForDatabase"
}

An ongoing agg with $out will cause dropDatabase to fail with:

{
	"ok" : 0,
	"errmsg" : "cannot perform operation: a background operation is currently running for collection pymongo_test.tmp.agg_out.b3feebc7-1f25-4ca6-afbc-c5a35758d671",
	"code" : 12587,
	"codeName" : "BackgroundOperationInProgressForNamespace"
}

Comment by Eric Milkie [ 25/Jan/20 ]

shane.harvey what new behavior? This ticket described a potential change in behavior that we wanted to make, but we never actually did it.

Comment by Shane Harvey [ 25/Jan/20 ]

matthew.russotto this new behavior (BackgroundOperationInProgressForDatabase/BackgroundOperationInProgressForNamespace) causes test failures in the Python driver (PYTHON-2068). Is this breaking change documented anywhere?

Comment by Matthew Russotto [ 09/Mar/18 ]

We still intend to completely remove resync (SERVER-31239), so I'm going to close this.

Comment by Eric Milkie [ 07/Mar/18 ]

It sounds like the real fix is to ensure that the test-only resync process kills all running operations before restarting initial sync. I believe rollback already has a similar requirement and was changed to wait until the background index builds complete.

Comment by Matthew Russotto [ 07/Mar/18 ]

It is the same as running the resync command:

https://github.com/mongodb/mongo/blob/master/buildscripts/resmokeconfig/suites/replica_sets_resync_static_jscore_passthrough.yml

It's a test-only command on replica sets

https://github.com/mongodb/mongo/blob/6be8b5a9cf495f1099b1fdd7d5aa8bb773b90d20/src/mongo/db/repl/resync.cpp#L85

Comment by Eric Milkie [ 05/Mar/18 ]

Is that the same as running the "resync" command? I thought we got rid of that.

Comment by Matthew Russotto [ 05/Mar/18 ]

This is the resync passthrough test; the background index was started and then a resync was executed.

Comment by Eric Milkie [ 03/Mar/18 ]

Why would a background index build be running when initial sync calls "dropAllDatabasesExceptLocal"?

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