Anybody seen this before in 4.0.23 sharded cluster?
2021-09-23T08:41:41.674+0200 I SHARDING [Balancer] Balancer move config.system.sessions: [{ _id: MinKey }, { _id: { id: UUID(“00400000-0000-0000-0000-000000000000”) } }), from s0,
to s3 failed :: caused by :: OperationFailed: Data transfer error: migrate failed: InvalidUUID: Cannot create collection config.system.sessions because we already have an identic
ally named collection with UUID 17d65f57-09b7-4335-91d5-92ef073cb6b9, which differs from the
donor’s UUID a6c3c5c8-8424-4a06-96a1-4082c349c6ff. Manually drop the collection on this shard if it contains data from a previous incarnation of config.system.sessions
Hello, @Konstantin_Manchev1 I ran into a similar issue and had to drop system.sessions collection from any router and let mongo recreate it after next logicalSessionRefresh. Although I had version 4.2.13. You might need to run flushRouterConfig from each router after dropping that collection or restart them one by one.
The log suggests to drop the collection but mongodb’s documentation clearly states not to drop collections from the config database.
That’s why we opened a jira ticket but we were told to raise the issue here in this forum, which we did (link follows as I’m not allowed to post more than 2 links in 1 message).
How did you succeed to drop the collection? Which user privileges did you use?