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

Make ShardingStateRecovery::endMetadataOp() persist the configTime as a preliminary step for removing ShardingStateRecovery

XMLWordPrintableJSON

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • Sharding EMEA 2022-08-08, Sharding EMEA 2022-08-22, Sharding EMEA 2022-09-05, Sharding EMEA 2022-09-19, Sharding EMEA 2022-10-03, Sharding EMEA 2022-10-17, Sharding EMEA 2022-10-31, Sharding EMEA 2022-11-14, Sharding EMEA 2022-11-28

      SERVER-60110 is aiming at removing the ShardingStateRecovery class, as the migration logic could directly interact with the VectorClock; nevertheless, there are scenarios in multiversion deployments that can only work if the oldest version guarantees that the configTime gets persisted at the end of a moveChunk/movePrimary operation.

      The purpose of this ticket is to ensure that versions 6.1+ and 7.0 make the configTime durable when ShardingStateRecovery::endMetadataOp() gets invoked, so that SERVER-60110 may be implemented as part of version 7.1

            Assignee:
            antonio.fuschetto@mongodb.com Antonio Fuschetto
            Reporter:
            paolo.polato@mongodb.com Paolo Polato
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: