MongoDb Version :4.0.3 Community
I have a mongodb cluster with dozens shard, and the data size in each shard reach TB level, the “db.collection.drop” takes me hours to complete。
I found the drop command is a serial operation. Is there any possibility that this could be changed to parallel ?
for (const auto& shardEntry : allShards) {
auto swShard = shardRegistry->getShard(opCtx, shardEntry.getName());
if (!swShard.isOK()) {
return swShard.getStatus();
}
const auto& shard = swShard.getValue();
auto swDropResult = shard->runCommandWithFixedRetryAttempts(
opCtx,
ReadPreferenceSetting{ReadPreference::PrimaryOnly},
nss.db().toString(),
dropCommandBSON,
Shard::RetryPolicy::kIdempotent);
if (!swDropResult.isOK()) {
return swDropResult.getStatus().withContext(
str::stream() << "Error dropping collection on shard " << shardEntry.getName());
}
auto& dropResult = swDropResult.getValue();
auto dropStatus = std::move(dropResult.commandStatus);
auto wcStatus = std::move(dropResult.writeConcernStatus);
if (!dropStatus.isOK() || !wcStatus.isOK()) {
if (dropStatus.code() == ErrorCodes::NamespaceNotFound && wcStatus.isOK()) {
// Generally getting NamespaceNotFound is okay to ignore as it simply means that
// the collection has already been dropped or doesn't exist on this shard.
// If, however, we get NamespaceNotFound but also have a write concern error then we
// can't confirm whether the fact that the namespace doesn't exist is actually
// committed. Thus we must still fail on NamespaceNotFound if there is also a write
// concern error. This can happen if we call drop, it succeeds but with a write
// concern error, then we retry the drop.
continue;
}
errors.emplace(shardEntry.getHost(), std::move(dropResult.response));
}