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

[Catalog] Adopt the improved repl interfaces to keep in-memory states in sync with data

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Catalog and Routing
    • 1

      SERVER-90360 introduced a new (and hopefully clearer and simpler) contract to help keep in-memory states with on-disk data.

      The contract is:

      ReplicaSetAwareInterface::onConsistentDataAvailable: In-memory states may choose to reconstruct here and
      subscribe to future writes from now on (e.g. via OpObservers). This is called

      • After replSetInitiate
      • After initial sync completes (for both logical and file-copy based initial sync)
      • After rollback to the stable timestamp
      • After storage startup from a stable checkpoint
      • After replication recovery from an unstable checkpoint

      ReplicationCoordinator::isDataConsistent: In-memory state may start tailing writes (e.g. via OpObservers) when this returns true.

      • Instead of checking member states, this function returns true after ReplicaSetAwareInterface::onConsistentDataAvailable is called.

      This ticket is to determine if we should adopt this for ShardingInitializationMongoD, ShardingRecoveryService, UserWritesRecoverableCriticalSectionService and VectorClockMongoD as well as ConfigServerOpObserver and ShardServerOpObserver (See git grep SERVER-91505).

            Assignee:
            Unassigned Unassigned
            Reporter:
            lingzhi.deng@mongodb.com Lingzhi Deng
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: