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

Conflict between initial sync setting the oldest timestamp and resharding pinning the oldest timestamp

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.0.0-rc0, 7.3.3, 7.0.11
    • Affects Version/s: None
    • Component/s: None
    • None
    • Replication
    • Fully Compatible
    • ALL
    • v7.3, v7.0, v6.0, v5.0
    • Repl 2024-03-04, Repl 2024-03-18
    • 123

      During the oplog application phase of initial sync we advance the oldest timestamp after applying each batch of oplog entries. We end up setting the oldest timestamp with force set to true. This ends up hitting an invariant if we applied a resharding oplog entry that requests to pin the oldest timestamp.

      I don't think that initial sync needs to use force when setting the oldest timestamp. In all cases we should be moving the oldest timestamp forward, and I think we only set the oldest timestamp during the oplog application phase to clean up history, so I think it should be fine to pin oldest back for an operation like resharding as long as the initial syncing node does not succeed in serving a read for resharding. On the other hand, we should not be able to do reads before the initialDataTimestamp anyways, so another option is that we ignore pinning the oldest timestamp if we are still in initial sync.

            Assignee:
            samy.lanka@mongodb.com Samyukta Lanka
            Reporter:
            samy.lanka@mongodb.com Samyukta Lanka
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: