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

(SA) Spike/Investigate Having a Single ServiceContext manage multiple shard roles

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Done
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None
    • Service Arch 2023-09-04, Service Arch 2023-09-18

    Description

      Part of our current potential design-plan to enable shards to act as routers involves registering dual implementations of modules that currently might be implemented separately on mongod and mongos with a single service context in a single process, and teaching the system to use the right modules given the 'shard role context' of the calling code. Some examples of these modules include commands, MongoProcessInterfaces used by query, ServiceEntryPoints used to dispatch commands, etc. User and system operations should be 'tagged' with the role they are utilizing the process as (i.e. router or shard), and that 'tag' should be used to dispatch to the module that tag corresponds to.

      We need to get a concrete estimation into what exactly will be involved in this work to produce an accurate timeline. In this ticket, we'll complete a spike of the work described above, in an attempt to run some subset of sharding-oriented tests against a mongod with an embedded router. We'll track what work was necessary to achieve this POC, what obstacles we identified to product-ionizing this work, and produce a time estimate of how long we'd expect this work to take.

      Attachments

        Activity

          People

            george.wangensteen@mongodb.com George Wangensteen
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: