-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
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.
- is related to
-
SERVER-63855 Make dbCheck work with resharding
- Backlog
- related to
-
SERVER-66046 Resharding coordinator won't automatically abort the resharding operation when a recipient shard errors during its applying phase
- Closed