Refreshing the logical session cache on a config server node will first check if the collection exists in the sharding catalog, and if this throws any error, refresh will try to create the collection by sending _shardsvrCreateCollection to the "first" shard in sorted order. This simulates the protocol for sending DDL operations to the primary shard for a database, but config.system.sessions exists in the "config" database, which doesn't have a "true" primary shard (ie no entry in config.databases for it). If the "first" shard was newly added to the cluster, it may not have the config.system.sessions collection locally, so if session refresh sends it _shardsvrCreateCollection (which may happen after any error today, e.g. InterruptedDueToReplStateChange), it may try to create the collection, despite it already existing on other shards. This always seems to fail sharding the collection, but can leave an untracked version of the collection on the "first" shard with a different UUID than the real, tracked sessions collection.
- is duplicated by
-
SERVER-77757 SessionsCollectionConfigServer::_shardCollectionIfNeeded swallows all types of errors
- Closed