Loading...
Loading...
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 abortActiveIndexBuilders(OperationContext* opCtx, const NamespaceString& collectionNs, CollectionUUID collectionUUID, const std::vector& 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.
JIRAUSER1265262 commented on Sat, 20 Jan 2024 01:25:46 +0000: 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.
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) }
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.