Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-58909

Missing versions for "admin" and "config" databases migrating to version 4.2

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.16
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

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

      Show
      Attached a JS test ( help-26155-simplified.js ) that reproduces the problem.
    • Sprint:
      Sharding EMEA 2021-08-09

      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.

        Attachments

        1. help-26155-simplified.js
          1.0 kB
          Antonio Fuschetto

          Issue Links

            Activity

              People

              Assignee:
              antonio.fuschetto Antonio Fuschetto
              Reporter:
              antonio.fuschetto Antonio Fuschetto
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: