Loading...

XML

Word

Printable

JSON

Type: Bug
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 5.3.0, 5.1.2, 5.0.6, 5.2.0-rc3
Affects Version/s: None
Component/s: Sharding
Labels:
None

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Backport Requested:

v5.2, v5.1, v5.0, v4.4
Sprint:
Sharding EMEA 2021-11-15, Sharding EMEA 2021-11-29, Sharding EMEA 2021-12-13, Sharding EMEA 2021-12-27
Linked BF Score:
46
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

ShardRegistry::reload() must never fail with ReadConcernMajorityNotAvailableYet but rather retry reading from the config server.

The retries should happen with exponential backoff capped to 30 seconds, in order to don't overwhelm the CSRS but - at the same - not retry after too long.

causes

SERVER-62386 Coverity analysis defect 121298: Parse warning

Closed

is related to

SERVER-57280 ShardRegistry must be initialized before DDL coordinators contact any shard

Closed

SERVER-57519 Make ARS use causally consistent ShardRegistry::getShard() function

Closed

related to

SERVER-60916 CPS Restores failed with a snapshot with documents in reshardingOperation

Closed

SERVER-62163 Complete TODO listed in SERVER-61003

Closed

SERVER-67896 Remove uncessary ShardRegistry reload retry logic

Closed

(1 related to)

Assignee:: Pierlauro Sciarelli
Reporter:: Pierlauro Sciarelli
Participants:: Githook User, Pierlauro Sciarelli
Votes:: 0 Vote for this issue
Watchers:: 3 Start watching this issue

Created:: Oct 26 2021 03:45:24 PM UTC
Updated:: Oct 29 2023 09:46:55 PM UTC
Resolved:: Dec 17 2021 07:03:56 PM UTC
Confidence Status Last Update:: 15/Dec/21 9:29 AM

Details

Description

Attachments

Issue Links

Activity

People

Dates