Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 5.0.4, 5.1.0-rc0
Affects Version/s: None
Component/s: Sharding
Labels:
- PM-234-M3
- PM-234-T-lifecycle

Backwards Compatibility:
Fully Compatible
Backport Requested:

v5.0
Sprint:
Sharding 2021-08-23
Story Points:
2
Confidence Status:
None
Work Order:
3
CAR Domain/s:
None

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

As discovered in this ticket and discussed in this [CR|https://mongodbcr.appspot.com/799100006.] The transaction in ShardingCatalogManager that makes sure the updates in
bumpCollectionVersionAndChangeMetadataInTxn happen atomically requires at least 5 GB of Wired Tiger cache size.

This is too large for an Atlas M30 to be able to handle as it has 8 GB of RAM and 50% of it is used for WT cache.

We need to investigate whether this is an issue and how to fix it.

related to

SERVER-68495 Resharding a collection with a very large number of zones configured may stall on config server primary indefinitely

Closed

SERVER-73763 Resharding does not extend zone ranges for config.tag docs, leading to config server primary fassert loop from duplicate key error

Closed

SERVER-73848 Hashed shard keys with zones can cause issues with resharding

Closed

SERVER-61035 Increase zones in 'resharding_large_number_of_initial_chunks.js' to 175,000

Closed

Assignee:: Luis Osta (Inactive)
Reporter:: Luis Osta (Inactive)
Participants:: Githook User, Luis Osta, Max Hirschhorn, Vivian Ge
Votes:: 0 Vote for this issue
Watchers:: 4 Start watching this issue

Created:: Jul 12 2021 03:06:29 PM UTC
Updated:: Oct 29 2023 09:51:04 PM UTC
Resolved:: Aug 31 2021 01:06:25 PM UTC

Details

Description

Attachments

Issue Links

Forms

Activity

People

Dates