[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: |
|
||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 7 | ||||||||||||||||||||||||||||||||||||
| Description |
|
Currently dropping a database while a background index build is in progress fails
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 ] | ||||||||||||
|
| ||||||||||||
| 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:
An ongoing agg with $out will cause dropDatabase to fail with:
| ||||||||||||
| 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 ( | ||||||||||||
| Comment by Matthew Russotto [ 09/Mar/18 ] | ||||||||||||
|
We still intend to completely remove resync ( | ||||||||||||
| 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: It's a test-only command on replica sets | ||||||||||||
| 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"? |