-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Sharding NYC
-
Fully Compatible
-
ALL
-
-
Sharding NYC 2023-04-03
On a cluster with a config-server replica set, we ban operations from mongos that would drop, rename or overwrite config database internal collections. This includes via drop command, renameCollection command and $out aggregation stage.
When running a cluster with a config-shard configuration, drop and $out are blocked, but renameCollection is allowed, and can be used to rename collections like config.chunks and config.shards.
It appears that the gating factor for this command on CSRS is whether the process is started with --shardsvr:
uncaught exception: Error: command failed: { "ok" : 0, "errmsg" : "Cannot accept sharding commands if not started with --shardsvr", "code" : 193, "codeName" : "NoShardingEnabled", "$clusterTime" : { "clusterTime" : Timestamp(1678213485, 33), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1678213485, 33) } with original command request: { "renameCollection" : "config.shards", "to" : "config.foo", "dropTarget" : false, "lsid" : { "id" : UUID("54900959-4b38-4e91-a349-a45c3d0002c9") }, "$clusterTime" : { "clusterTime" : Timestamp(1678213485, 33), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } }
- is related to
-
SERVER-74734 After renaming the "config.shards" collection, attempting to rename it back can cause a deadlock
- Closed
-
SERVER-88675 DDL commands against config and admin database are not allowed via a router but are allowed via a direct connection to the config server or shard
- Backlog