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

Evaluate the effectiveness of propagating shard version via mirrored reads

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

      A newly-elected shard primary can block serving user operations while waiting to install sharding metadata. This process can take a long time for users with lots of config metadata. To address this issue, in SERVER-55412 began mirroring the ShardVersion field to secondaries, so that they would be more likely to incrementally keep their sharding information up-to-date, and have less to refresh after an election.

       

      We should compare the time-to-first-majority write after an election on a replica set vs. a sharded cluster, to ensure this feature is working. We should experiment with different values of the ratio of reads we mirror, to examine the sensitivity. We should be particular to examine a case where there are lots of collections, which implies more metadata to refresh. 

            Assignee:
            Unassigned Unassigned
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: