[SERVER-85284] Two or more indexes being created cannot be terminated normally Created: 17/Jan/24  Updated: 30/Jan/24

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: 7.0.6, 5.0.25, 4.4.29, 6.0.14
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: FirstName lipengchong Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: Bug, storex-ranked
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Operating System: ALL
Steps To Reproduce:

createIndex with a big table in different createIndex

db.ycsb_test_1705397142.createIndex({field5:1},{background:false}) 

db.ycsb_test_1705397142.createIndex({field4:1},{background:false}) 

 

then dropIndexes

xxx:PRIMARY> db.runCommand({dropIndexes:"ycsb_test_1705397142",index:["field5_1","field4_1"]})
{
        "operationTime" : Timestamp(1705489578, 2),
        "ok" : 0,
        "errmsg" : "cannot perform operation: a background operation is currently running for collection ycsb.ycsb_test_1705397142",
        "code" : 12587,
        "codeName" : "BackgroundOperationInProgressForNamespace",
        "$gleStats" : {
                "lastOpTime" : {
                        "ts" : Timestamp(1705489578, 2),
                        "t" : NumberLong(7)
                },
                "electionId" : ObjectId("7fffffff0000000000000007")
        },
        "lastCommittedOpTime" : Timestamp(1705489578, 2),
        "$configServerState" : {
                "opTime" : {
                        "ts" : Timestamp(1705489581, 2),
                        "t" : NumberLong(1)
                }
        },
        "$clusterTime" : {
                "clusterTime" : Timestamp(1705489584, 1),
                "signature" : {
                        "hash" : BinData(0,"VardSR5SDw0tB6/DTSC4h1YedKc="),
                        "keyId" : NumberLong("7313775769702891542")
                }
        }
} xx:PRIMARY> db.runCommand({dropIndexes:"ycsb_test_1705397142",index:"*"})
{
        "nIndexesWas" : 3,
        "msg" : "non-_id indexes dropped for collection",
        "ok" : 1,
        "$gleStats" : {
                "lastOpTime" : {
                        "ts" : Timestamp(1705491657, 3),
                        "t" : NumberLong(7)
                },
                "electionId" : ObjectId("7fffffff0000000000000007")
        },
        "lastCommittedOpTime" : Timestamp(1705491653, 1),
        "$configServerState" : {
                "opTime" : {
                        "ts" : Timestamp(1705491651, 2),
                        "t" : NumberLong(1)
                }
        },
        "$clusterTime" : {
                "clusterTime" : Timestamp(1705491657, 3),
                "signature" : {
                        "hash" : BinData(0,"N0pxt8jtjreOWpAGsyfA8aC+D3Y="),
                        "keyId" : NumberLong("7313775769702891542")
                }
        },
        "operationTime" : Timestamp(1705491657, 3)
}

Participants:

 Description   

After 4.4 version, index creation is done in the background, and is Simultaneous Indexing. We can execute dropIndexes to terminate the index being created.
 
But there is such a scene:
In a terminal creates an index named of a_1 for collection mycoll ; and another one creates an index named of b_1 for collection mycoll;
 
That is, table mycoll has two indexes being created, with different buildUUIDs
 
and now ,i will get errores when terminate the indexes
 

cannot perform operation: a background operation is currently running for collection ycsb.mycoll

 
I have to drop all the indexes on this table to drop the two indexes that were created, but that's not what I want.
 
The key point is that the logic of deleting indexes does not support this scenario. It only supports the scenario of creating multiple indexes with the same buildUUID.
 
 

/**
 * Aborts all the index builders on the collection if the first element in 'indexesToAbort' is "*",
 * otherwise this attempts to abort a single index builder building the given index names.
 */
std::vector<UUID> abortActiveIndexBuilders(OperationContext* opCtx,
                                           const NamespaceString& collectionNs,
                                           CollectionUUID collectionUUID,
                                           const std::vector<std::string>& indexNames) {
    if (indexNames.empty()) {
        return {};
    }    if (indexNames.front() == "*") {
        return IndexBuildsCoordinator::get(opCtx)->abortCollectionIndexBuilds(
            opCtx, collectionNs, collectionUUID, "dropIndexes command");
    }    return abortIndexBuildByIndexNames(opCtx, collectionUUID, indexNames);
}

 
 
Maybe this is a bug and this scenario should be supported.



 Comments   
Comment by Chris Kelly [ 20/Jan/24 ]

Hi! 

Thanks for your report! 

Starting in MongoDB 5.2, you should be able to use dropIndexes to drop existing indexes on the same collection even if there is a build in progress on another index. In earlier versions, attempting to drop a different index during an in-progress index build results in a BackgroundOperationInProgressForNamespace error.

When I try creating these two indexes on a large collection, and attempt to drop them using  {{

{dropIndexes:"yourCollection",index:["field1_1","field2_1"]}

}} :

 

Version Simultaneous Index Builds Shell background error
7.0.5 2 Legacy false can't drop unfinished index with name: field1_1"
7.0.5 1 Legacy false

 

replset:PRIMARY> db.runCommand({dropIndexes:"yourCollection",index:["field1_1","field2_1"]})
{
        "ok" : 0,
        "errmsg" : "can't drop unfinished index with name: field1_1",
        "code" : 27,
        "codeName" : "IndexNotFound",
        "$clusterTime" : {
                "clusterTime" : Timestamp(1705535237, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1705535237, 1)
}

 

I am assigning this to the relevant team to take a further look.

Generated at Thu Feb 08 06:57:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.