[SERVER-58909] Missing versions for "admin" and "config" databases migrating to version 4.2 Created: 28/Jul/21  Updated: 29/Oct/23  Resolved: 03/Aug/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.2.16

Type: Bug Priority: Major - P3
Reporter: Antonio Fuschetto Assignee: Antonio Fuschetto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File help-26155-simplified.js    
Issue Links:
Depends
Related
is related to SERVER-58805 InternalError: DatabaseVersion doesn'... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Attached a JS test (help-26155-simplified.js) that reproduces the problem.

Sprint: Sharding EMEA 2021-08-09
Participants:

 Description   

MongoDB 4.0 does not provide versions for admin and config databases. This information has been introduced in MongoDB 4.2 and the management of local sessions needs to known the version of the config database.

A problem occurs during the upgrade process, where the binaries of the secondary shards are upgraded before the primary (as suggested in the migration guide). In this scenario, the config database metadata update is implicitly triggered by session management at the secondary shard level (MongoDB 4.2), but this information is not provided by the primary shard as it does not yet support it (MongoDB 4.0).

It follows the detailed workflow that triggers the problem:

  1. After a binary upgrade to version 4.2, the secondary shard forces a config database metadata refresh
  2. The secondary shard accesses to SSCCL and forces a refresh on primary, thus waits for replication
  3. The primary shard (version 4.0) accesses to SSCCL which forwards a request of metadata update to the config server through the CSCCL
  4. CSCCL intercepts that the request is related to the special database (i.e. config) and returns a built-on-fly database type (without version as that’s a shard version 4.0)
  5. The secondary shard receives the replication and finds incomplete database metadata in locally-persisted cache (i.e. config.cache.databases)

When the problem is triggered, the following error appears in the logs: InternalError: DatabaseVersion doesn't exist in database entry { _id: "config", partitioned: true, primary: "config" } despite the shard being in binary version 4.2 or later.



 Comments   
Comment by Githook User [ 02/Aug/21 ]

Author:

{'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}

Message: SERVER-58909 Missing versions for admin and config databases migrating to version 4.2
Branch: v4.2
https://github.com/mongodb/mongo/commit/790c3cc1b131bed9c84e3650999cd286811c5f05

Comment by Antonio Fuschetto [ 02/Aug/21 ]

linda.qin from the Customer Support team confirmed that the customer's problem was resolved as soon as the primary shard was also updated to version 4.2. This confirms my assumption. Therefore, as far as I can understand possible scenarios, it seems that it is enough to fix the branch 4.2 and not the higher ones.

Generated at Thu Feb 08 05:45:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.