Avoid resharding recipient cache invalidation/refresh during initialization for no-chunks detection

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Cluster Scalability
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      During resharding recipient initialization, the recipient currently invalidates its cache and refreshes metadata to determine whether it owns any chunks. That result is then used to set the appropriate skip flags in the recipient state document, which are later copied into boolean fields in the recipient state machine constructor.

      In the shard-authoritative model, it is more appropriate for the coordinator to tell the recipient whether it will own any chunks, since that information is already known to the coordinator. There are two options that could allow us to avoid this logic in the initialize command:

      1. Consider using the clone command metrics as an indication that this recipient will not own any chunks. We effectively already get this for free because the coordinator is required to send a personalized clone command to recipients that will not clone with cloning metrics set to 0.
      2. Pass a boolean flag in the initialize command to tell the recipient that it will not own any chunks and should skip cloning, index building, and oplog application.

       

      Option 1 is more directly aligned with the underlying decision point, since the recipient primarily needs this information to decide whether it should clone at all.

            Assignee:
            Unassigned
            Reporter:
            Kruti Shah
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: