[SERVER-72322] The 'forceShardFilteringMetadataRefresh' methods don't synchronise with each other (4.4 and 4.2 only) Created: 21/Dec/22  Updated: 06/Feb/24

Status: Open
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.2.0, 4.4.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Sergi Mateo Bellido
Resolution: Unresolved Votes: 0
Labels: shardingemea-qw
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-40258 Relax locking requirements for shardi... Closed
Related
related to SERVER-42838 A slow thread in forceShardFilteringM... Closed
is related to SERVER-64730 The 'forceShardFilteringMetadataRefre... Closed
Assigned Teams:
Sharding EMEA
Operating System: ALL
Sprint: Sharding EMEA 2023-10-16, Sharding EMEA 2023-10-30, CAR Team 2023-11-13, CAR Team 2023-11-27, CAR Team 2023-12-11, CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19
Participants:
Story Points: 3

 Description   

This ticket is a specialization of SERVER-64730, to track this issue on 4.4 and 4.2 branches.

The forceShardFilteringMetadataRefresh method is the lowest-level shard version causality utility on the shards, whose purpose is to always move the shard version forward.

In versions 4.0 and earlier, it used to acquire collection X lock and check that the newly installed version is actually newer than the one on the CSS before installing it. Starting from version 4.2 though, as part of the transaction project it was changed to not acquire collection X-lock.

This means that two concurrent invocations of forceShardFilteringMetadataRefresh could potentially race with each other and install non-monotonous increasing versions (i.e., the shard version on a shard can go back in time).


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