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

config.transactions table can get out of sync when the TransactionReaper remove entries

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.7.1
    • Fix Version/s: 3.6.4, 3.7.3
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v3.6
    • Sprint:
      Sharding 2018-02-12, Sharding 2018-02-26, Sharding 2018-03-12, Sharding 2018-03-26
    • Linked BF Score:
      0

      Description

      Background: Updates to the config.transactions table don't generate oplog entries and are replicated differently in the secondaries. The primary store all the relevant information in the oplog of the write that would update the config.transactions table and the secondaries reconstruct the table from this. Because of how oplog application is parallelized, the order it gets applied cannot be guaranteed. Fortunately, there is a simple rule that is used: higher transaction number wins, and if tied, higher lastWriteOpTime wins. So as an optimization, the secondary simply squash all changes to the same session to a single update and apply them at the end of the batch.

      So the issue is when someone (like the TransactionReaper) deletes an entry in config.transactions, it will generate an oplog entry for the delete. When the secondary applies this delete oplog, the transaction is correctly deleted. But if there are updates on the transactions table for the same oplog batch, then it can "revive" back again, creating an orphan entry and making it inconsistent with the current primary.

      Note: that likelihood of this happening is low since the reaper only cleans up entries that are not active for more than 30 min.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              renctan Randolph Tan
              Reporter:
              renctan Randolph Tan
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: