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

Enable internal_transactions_resharding.js in the concurrency_sharded_multi_stmt_txn_with_balancer suite

    • Fully Compatible
    • Sharding 2022-06-27

      This suite runs the RunDBCheckInBackground hook. The hook runs the dbCheck command which generates {op: "c"} oplog entries as follows:

      { oplogEntry: { op: \"c\", ns: \"test0_fsmdb0.fsmcoll0\", ui: UUID(\"07b07822-7c51-410d-85e2-c5d5d4060998\"), o: { dbCheck: \"test0_fsmdb0.fsmcoll0\", type: \"batch\", md5: \"d381a905564387e42a68127855fecdf6\", minKey: MinKey, maxKey: MaxKey, readTimestamp: Timestamp(1651051063, 135), applyOps: null }, ts: Timestamp(1651051063, 156), t: 1, v: 2, wall: new Date(1651051063854), _id: { clusterTime: Timestamp(1651051063, 156), ts: Timestamp(1651051063, 156) } } }"}

      Resharding doesn't ignore dbCheck oplog entries but it expects every {op: "c"} oplog entry to be an applyOps oplog entry or commitTransaction oplog entry or abortTransaction oplog entry. So upon seeing a dbCheck oplog entry, the ReshardingRecipientService would throw OplogOperationUnsupported here, and that would cause the resharding operation to fail/hang. dbCheck is a read-only operation so resharding should ignore dbCheck oplog entries. There is already a ticket for addressing this (SERVER-63855). Once that ticket is complete, we should be able to enable the internal_transactions_resharding.js run in that suite.

            erin.liang@mongodb.com Erin Liang
            cheahuychou.mao@mongodb.com Cheahuychou Mao
            0 Vote for this issue
            5 Start watching this issue