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

Committing or aborting prepared transactions may fail to un-pin stable timestamp

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.8
    • Affects Version/s: None
    • Component/s: Replication
    • Fully Compatible
    • ALL
    • Repl 2018-12-17, Repl 2019-01-14
    • 62

      When calculating the stable timestamp, the replication coordinator does not allow it to advance beyond the oplog entry timestamp of the oldest uncommitted/aborted prepared transaction. This timestamp is maintained in the ServerTransactionMetrics service context decoration which is updated through the TransactionParticipant's TransactionMetricsObserver object when a transaction prepares, commits, or aborts a transaction.

      It looks like the metrics are updated after the commit oplog entry is written in a side transaction, so if the commit point advances to include the commit's opTime before the transaction metrics are updated, a recalculation of the stable timestamp will be triggered, but the replication coordinator will not know it can advance the stable timestamp to include the commit oplog entry. The next operation to trigger a calculation of the stable timestamp will be able to advance to include the commit, but if nothing triggers a new calculation, anything waiting for a new committed snapshot will hang. This seems possible when aborting a prepared transaction as well.

      A similar problem exists with prepare, because we also commit the prepare oplog entry before updating the oldest prepared timestamp in the transaction metrics, although this should lead to incorrectly advancing the stable timestamp instead of incorrectly holding it back.

            pavithra.vetriselvan@mongodb.com Pavithra Vetriselvan
            jack.mulrow@mongodb.com Jack Mulrow
            0 Vote for this issue
            5 Start watching this issue