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

Investigate if shard merge can ensure eventually consistent fast count with reasonable effort.

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

      Collection statistics are exposed by "db.stats()" and  "count()" commands. They are stored in 2 different WT tables:

      • sizeStorer.wt contains dataSize, objects (aka numRecords, used by "count()" command)
      • WiredTiger.wt contains storageSize, freeStorageSize, indexSize, indexFreeStorageSize, etc.

      Both kinds of information are copied from D to R via a temporary WiredTiger instance. The sizeStorer.wt table is synced from in-memory stats every 60 seconds, so the copied info will probably be stale, leading to inaccurate fast count forever.

      PM-2947 will be redesigning the fast count tracking mechanism and ensure eventual fast count consistency. After PM-2947 completion, we will use this ticket to investigate if Merge can ensure eventually consistent fast count with reasonable effort. 

            Assignee:
            backlog-server-cluster-scalability [DO NOT USE] Backlog - Cluster Scalability
            Reporter:
            suganthi.mani@mongodb.com Suganthi Mani
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: