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

Coordinator should make configOpTime durable before sending prepare

    • Type: Icon: Bug Bug
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Sharding
    • Sharding
    • ALL
    • Sharding 2019-08-12, Sharding 2019-08-26

      ...and shard primaries should read the configOpTime and wait for it to become durable on stepup, before resuming coordinating commits.

      Otherwise, a new coordinator primary might assume a participant shard has received the decision, even though it hasn't. Example:

      1. Coordinator Primary 1 (P1) sends prepare to Shard A
      2. Shard A enters prepare
      3. P1 steps down, Coordinator Primary 2 (P2) resumes the coordination and refreshes its ShardRegistry from a stale config server which doesn't have Shard A
      4. P2 gets ShardNotFound for Shard A and treats the ShardNotFound as an ack.
      5. Shard A remains in prepare forever.

      The suggested fix implementation is to:

      1) make coordinators update the configOpTime in the minOpTimeRecovery document along with writing the participant list, here. (The coordinator then waits for writeConcern, which would cover both writes).

      2) make the "recover pending commits on stepup" task load the persisted configOpTime into memory before waiting for writeConcern

            Assignee:
            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            Reporter:
            esha.maharishi@mongodb.com Esha Maharishi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: