[SERVER-42192] Write a concurrency workload to test that orphaned ranges are always deleted and nothing that shouldn’t be deleted gets deleted Created: 11/Jul/19  Updated: 29/Oct/23  Resolved: 18/Mar/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.4.0-rc0, 4.7.0

Type: Task Priority: Major - P3
Reporter: Alexander Taskov (Inactive) Assignee: Max Hirschhorn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
is duplicated by SERVER-40713 Enable fsm workloads that use moveChu... Closed
Related
related to SERVER-46386 Refining a shard key may lead to an o... Closed
related to SERVER-46395 Resumable range deleter can submit du... Closed
related to SERVER-46669 moveChunk may succeed but not respect... Closed
related to SERVER-47761 moveChunk command in stepdown suites ... Closed
is related to SERVER-42473 Create concurrency workload to valida... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.4
Sprint: Sharding 2020-03-09, Sharding 2020-03-23
Participants:

 Description   
  • Doing a write
  • Migrating a chunk
  • Stepping down a shard
  • Waiting for the RangeDeletionScheduler to empty its queue, and then checking that no orphaned documents exist and that all documents that are supposed to exist do exist


 Comments   
Comment by Githook User [ 06/Apr/20 ]

Author:

{'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}

Message: SERVER-42192 Unblacklist refine shard key test from stepdown suites.

(cherry picked from commit 9e10d4f30058fcc7a2a770cac6148c1fdc2a83ac)
Branch: v4.4
https://github.com/mongodb/mongo/commit/3a095b52f9eaa6eb79b42f2d8265794bb9c860d2

Comment by Githook User [ 06/Apr/20 ]

Author:

{'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}

Message: SERVER-42192 Enable moveChunk FSM workloads to run in stepdown suites.

Adds automatic retry logic to ChunkHelper.moveChunk() to handle when the
CSRS or replica set shard primary being killed, terminated, or stepped
down leads to the moveChunk command being interrupted.

Exposes replica set connections as part of the "connection cache" so
that DBClientRS may be used to track the current primary of the CSRS or
replica set shard.

Introduces an fsm.forceRunningOutsideTransaction() utility function to
prevent a state function from running inside a multi-statement
transaction as part of the concurrency__multi_stmt_txn.yml test
suites.

(cherry picked from commit 5eeb0955011cf96d0218ac0a9d7f54adc9584173)
Branch: v4.4
https://github.com/mongodb/mongo/commit/d3d2f979c9420056609d1bc06bc1756887d524e3

Comment by Githook User [ 17/Mar/20 ]

Author:

{'email': 'max.hirschhorn@mongodb.com', 'name': 'Max Hirschhorn', 'username': 'visemet'}

Message: SERVER-42192 Unblacklist refine shard key test from stepdown suites.
Branch: master
https://github.com/mongodb/mongo/commit/9e10d4f30058fcc7a2a770cac6148c1fdc2a83ac

Comment by Githook User [ 12/Mar/20 ]

Author:

{'name': 'Max Hirschhorn', 'username': 'visemet', 'email': 'max.hirschhorn@mongodb.com'}

Message: SERVER-42192 Enable moveChunk FSM workloads to run in stepdown suites.

Adds automatic retry logic to ChunkHelper.moveChunk() to handle when the
CSRS or replica set shard primary being killed, terminated, or stepped
down leads to the moveChunk command being interrupted.

Exposes replica set connections as part of the "connection cache" so
that DBClientRS may be used to track the current primary of the CSRS or
replica set shard.

Introduces an fsm.forceRunningOutsideTransaction() utility function to
prevent a state function from running inside a multi-statement
transaction as part of the concurrency__multi_stmt_txn.yml test
suites.
Branch: master
https://github.com/mongodb/mongo/commit/5eeb0955011cf96d0218ac0a9d7f54adc9584173

Comment by Jack Mulrow [ 10/Feb/20 ]

Here's the test I was referring to: sharded_moveChunk_partitioned.js. In particular, here's where it verifies mongos sees every document that was in the moved chunk.

Comment by Esha Maharishi (Inactive) [ 10/Feb/20 ]

jack.mulrow, you mentioned there is an existing concurrency test that provides this coverage, do you mind linking it here? Maybe we can just modify it to wait for config.rangeDeletions to be empty before asserting that no real data was deleted.

Generated at Thu Feb 08 04:59:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.