Differenciate VectorClock persist behavior based on cluster role

XMLWordPrintableJSON

    • Fully Compatible
    • Sharding 2020-07-13, Sharding 2020-07-27, Sharding 2020-08-10
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      The persist method introduced in SERVER-48717 should behave in different ways depending on the cluster role.

      • Config server: don’t do anything because configTime and topologyTime are guaranteed from the oplog (last optimes on oplog)
      • Shard primary: call create/update with majority write concern
      • Shard secondary: call waitForInMemoryVectorClockToBePersisted on the primary (a PersistVectorClockCommand need to be created)

              Assignee:
              Pierlauro Sciarelli
              Reporter:
              Pierlauro Sciarelli
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: