File WiredTigerHS.wt size uncotrolled growth during resharding big collection

Ops and Admin Sharding
,
1

Hi there.
Mongodb v5.0.18 production db (has been gradually updated from v4.0).
750Gb sharded collection on 3 replicasets.

Some time after the start of the reshardCollection process , a constant growth in WiredTigerHS.wt size begins.
After a 24h of the process (~70-75% of progress), this size reaches more than 1 TB on one of the shards. Had to cancel process due to running out of space.

320G	/data/WiredTigerHS.wt
mongodb-sh1-3
280G	/data/WiredTigerHS.wt
mongodb-sh2-1
1.1T	/data/WiredTigerHS.wt
mongodb-sh2-2
1.1T	/data/WiredTigerHS.wt
mongodb-sh2-3
993G	/data/WiredTigerHS.wt
mongodb-sh3-1
454G	/data/WiredTigerHS.wt
mongodb-sh1-2 
307G	/data/WiredTigerHS.wt
mongodb-sh3-2
442G	/data/WiredTigerHS.wt
mongodb-sh3-3
600G	/data/WiredTigerHS.wt

minSnapshotHistoryWindowInSeconds parameter is set to 300sec (default).

During the resharding, our service is still working, but less active than usual (users have been warned).
Is it normal for the transaction history file to grow?
Is there any way to solve this without resorting to increasing the disk size?
We do not use Point-in-Time backups, so the size of the stored transactions history is not important.
We are unable to update the mongodb version at the moment.

Couldn’t find a similar situation anywhere.

2

it’s internal to wiredtiger logic, not a mongodb employee so i can’t help. But check this:

3

thanks, i read this topic. There is a different situation and it could not be solved: the database was restored from a snapshot.
It’s just that if this is a regular situation, it is not clear why the documentation does not indicate this - it only requires 1.2x the size of the collection free disk space on each shard member.