[SERVER-73255] Make sure that query sampling handles WouldChangeOwningShard updates correctly Created: 24/Jan/23  Updated: 29/Oct/23  Resolved: 02/Feb/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0-rc0

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Cheahuychou Mao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding NYC 2023-02-06
Participants:

 Description   

Currently, a shard key update that causes a document to move from one shard to another works as follows:

  1. The client sends the update to some mongos.
  2. The mongos forwards the update to the shard that owns the pre-update shard key value.
  3. The shard throws WouldChangeOwningShard error.
  4. If the update isn't running in a transaction, the mongos starts an internal transaction and retry to update to make sure that it still fails with a WouldChangeOwningShard error.
  5. The mongos sends a delete the shard that owns the pre-update shard key value and an insert to the shard key that owns the post-update shard key.
  6. The mongos commits the (internal) transaction.

Without additional handling, the additional WouldChangeOwningShard update and a delete may get sampled, and result in a sample population that is not representative of the user's workload. In addition, since the update is executed using a delete and an insert, it will show up in the OpObserver as an update so no diff will be sampled. So they will no get counted as a shard key update by the analyzeShardKey command. 



 Comments   
Comment by Githook User [ 02/Feb/23 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-73255 Make sure that query sampling handles WouldChangeOwningShard updates correctly
Branch: master
https://github.com/mongodb/mongo/commit/9ab4df8b48b07fe9737527453e10f092b6c34d0b

Generated at Thu Feb 08 06:24:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.