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

[4.4] Index build abort can set ghost timestamps on primaries

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • ALL
    • Hide

      Apply this patch:

      diff --git a/src/mongo/db/catalog/multi_index_block.cpp b/src/mongo/db/catalog/multi_index_block.cpp
index f08446efb6..d2a94dac78 100644
--- a/src/mongo/db/catalog/multi_index_block.cpp
+++ b/src/mongo/db/catalog/multi_index_block.cpp
@@ -115,6 +115,8 @@ void MultiIndexBlock::abortIndexBuild(OperationContext* opCtx,
                 repl::UnreplicatedWritesBlock uwb(opCtx);
                 if (!IndexTimestampHelper::setGhostCommitTimestampForCatalogWrite(opCtx, nss)) {
                     LOGV2(20382, "Did not timestamp index abort write.");
+                } else {
+                    LOGV2_FATAL(0, "Wrote ghost timestamp for index abort write.");
                 }
             }

      And run:

      resmoke run --suite=no_passthrough jstests/noPassthrough/index_stepdown_abort_prepare_conflict.js
      Show
      Apply this patch: diff --git a/src/mongo/db/catalog/multi_index_block.cpp b/src/mongo/db/catalog/multi_index_block.cpp index f08446efb6..d2a94dac78 100644 --- a/src/mongo/db/catalog/multi_index_block.cpp +++ b/src/mongo/db/catalog/multi_index_block.cpp @@ -115,6 +115,8 @@ void MultiIndexBlock::abortIndexBuild(OperationContext* opCtx, repl::UnreplicatedWritesBlock uwb(opCtx); if (!IndexTimestampHelper::setGhostCommitTimestampForCatalogWrite(opCtx, nss)) { LOGV2(20382, "Did not timestamp index abort write." ); + } else { + LOGV2_FATAL(0, "Wrote ghost timestamp for index abort write." ); } } And run: resmoke run --suite=no_passthrough jstests/noPassthrough/index_stepdown_abort_prepare_conflict.js
    • Execution Team 2020-06-01, Execution Team 2020-06-15, Execution Team 2021-02-08
    • 22

      When aborting an index build, we determine whether or not to write a ghost timestamp through a call to "getCommitTimestamp" here, however this only returns a timestamp on secondaries.

      On primaries, this is always false, and results in a call to RecoveryUnit::setTimestamp.

      This is immediately followed by a call to write an abortIndexBuild oplog entry via the onCleanUp handler. This overwrites and updates the commit timestamp, so the catalog write ends up being timestamped correctly.

      TLDR: I believe this can temporarily cause the WiredTiger "all_durable" value to move backwards, which violates the contract "all_durable" on primaries.

      Say, for example, there are no open WT transactions. Both lastApplied and "all_durable" all 10. If I open a WT transaction and set its commit timestamp to 10 (a timestamp that has already been committed), "all_durable" will move backwards to 9. After the transaction commits, "all_durable" can advance back to 10.

            Assignee:
            louis.williams@mongodb.com Louis Williams
            Reporter:
            louis.williams@mongodb.com Louis Williams
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: