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

minClusterTime filtering can filter out primary

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

      When targeting configServer nodes, we use the minClusterTime as a best effort to filter out stale nodes with respect to the desired configTime. Considering the clusterTime for the node as cached by the RSM can be stale up to 10 seconds and the clusterTimes of each replica are obtained non-atomically and in no specific order, we can end up filtering out the primary. Conceptually, it is impossible for a primary to be more stale than a secondary, shouldn't the recency filter always include primary nodes? (Assuming we somehow fix SERVER-81910, as otherwise we might always target the primary) The streamable replica set monitor guarantees that the primary/secondary knowledge is updated almost immediately (at most as late as the latency to the nodes).

            Assignee:
            Unassigned Unassigned
            Reporter:
            yujin.kang@mongodb.com Yujin Kang Park
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: