Cannot create collection config.system.sessions because we already have an identically named collection

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.

1 Like

Thanks Divyanshu ,

I have suceeded with different steps , but still wondering if this is the correct way:

  1. Drop the system.sessions collections in affected shards. ( require some additional privileges to be set ):
db.getSiblingDB('config').system.sessions.drop()
  1. Re-create the system.sessions on the shards PRIMARY with the donor’s UUID:
var uuid = UUID("a6c3c5c8-8424-4a06-96a1-4082c349c6f1");
var ops = [{ "op": "c","ns": "config.$cmd","ui": uuid,"o": {"create": "system.sessions","idIndex": {"v": 2, "key": {"_id": 1}, "name": "_id_", "ns": "config.system.sessions"} } }];
db.adminCommand({applyOps: ops});

But your steps looks safer …
Cheers,
Konstantin

We had (and still have) the same issue.

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?

Thanks!

1 Like

link of the issue

It works with either the build in system privilege:

db.createUser({ user: "t2", pwd: "xxx", roles: [ "__system" ] })

or the custom created:

db.createRole( {
   role: "executeFunctions",
   privileges: [ { resource: { anyResource: true }, actions: [ "anyAction" ] } ], roles: []
})
 
db.createUser({ user: "t3", pwd: "xxx", roles: [ "executeFunctions" ] })
1 Like

after the re-creation you will get messages like this:

2021-10-03T23:00:32.559+0200 I QUERY    [LogicalSessionCacheReap] Unable to establish remote cursors - {error: StaleConfig{ ns: "config.system.sessions", vReceived: Timestamp(513, 1), vReceivedEpoch: ObjectId('6
15a1224219459781e394ce6'), vWanted: Timestamp(0, 0), vWantedEpoch: ObjectId('000000000000000000000000') }: epoch mismatch detected for config.system.sessions, the collection may have been dropped and recreated,
numActiveRemotes: 0}

But I suppose it is normal and those are due to the removed ongoing sessions only …

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.