[SERVER-32368] do not perform UUID check against a shard's config cache in the sharding_csrs_continuous_config_stepdown_WT suite Created: 15/Dec/17  Updated: 30/Oct/23  Resolved: 13/Feb/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.0
Fix Version/s: 3.6.3, 3.7.3

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

Issue Links:
Backports
Depends
Related
related to SERVER-31605 Un-blacklist cross-version UUID checks Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6
Sprint: Sharding 2018-02-12, Sharding 2018-02-26
Participants:
Linked BF Score: 0

 Description   

In the stepdown suite, if the config server primary steps down during shardCollection just before sending setShardVersion to the primary shard, the primary shard may never receive setShardVersion, therefore never refresh its cache for the collection, and so not have an entry in its cache for the collection.

This causes the UUID check that compares the UUID on the config server with the UUID in a shard's cache to fail.

We should not perform this check in the stepdown suite, until it is guaranteed that a shard refreshes its cache after shardCollection.



 Comments   
Comment by Githook User [ 13/Feb/18 ]

Author:

{'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}

Message: SERVER-32368 do not perform UUID check against a shard's config cache in the sharding_csrs_continuous_config_stepdown_WT suite

(cherry picked from commit fe5b3058c3ba27f8262fa5198cf243053ba50b9b)
Branch: v3.6
https://github.com/mongodb/mongo/commit/bb5a78f22349bb67cfe64271662e59ded1f86cb2

Comment by Githook User [ 13/Feb/18 ]

Author:

{'email': 'esha.maharishi@mongodb.com', 'name': 'Esha Maharishi', 'username': 'EshaMaharishi'}

Message: SERVER-32368 do not perform UUID check against a shard's config cache in the sharding_csrs_continuous_config_stepdown_WT suite
Branch: master
https://github.com/mongodb/mongo/commit/fe5b3058c3ba27f8262fa5198cf243053ba50b9b

Comment by Dianna Hohensee (Inactive) [ 01/Feb/18 ]

kaloian.manassiev esha.maharishi This is occurring in index1.js once a day on average. Could you make a ticket to blacklist index1.js and get it in soon?

Comment by Kaloian Manassiev [ 12/Jan/18 ]

I'd say, let's do it. I don't think we have seen it catch any real bugs recently and it's only causing BF noise.

esha.maharishi, if you sketch approximately where the fix should go, I will find someone to do it in next week's iteration.

Comment by Gregory McKeon (Inactive) [ 12/Jan/18 ]

esha.maharishi kaloian.manassiev If this is easy, can we prioritize it? It's leading to a non-zero number of duplicate BF's on the sharding team.

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