There may be several reasons:
1)Rare checkpoints;
2)Historical rebalancing;
3)Large transactions.
reason='too big size of WAL without checkpoint' - means that there are too many
segments without a checkpoint.This is possible with a heavy data load.
01.03.2021, 19:35, "narges saleh" :
> Hi All,
>
Hi, the problem has already been fixed, but it was not included in the latest
release.
https://issues.apache.org/jira/browse/IGNITE-14952
28.09.2021, 10:33, "Lo, Marcus" :
> Hi,
>
> We are encountering an interesting scenario, where the total WAL archive size
> is larger than max archive size,
Yes, this is the expected behavior, these segments can still be used, for
example, during a historical rebalance.
28.09.2021, 11:03, "Lo, Marcus" :
> Hi all,
>
> I am trying wal archive compaction by enabling walCompactionEnabled. However
> after enabling it I can see both the unzipped and zippe
duce the disk space
> occupied by WAL archive, but in that case does it mean that by enabling the
> feature it occupies more space instead of less? Thanks.
>
> Regards,
> Marcus
>
> -Original Message-
> From: [External] ткаленко кирилл
> Sent: Tuesday, September 28, 2021
Cleaning takes place in a separate thread.
Transfer of segments occurs in a separate thread after the checkpoint.
Checkpoints happen in the following cases: on timeout, but padding one of the
persistent data region by 0.75 (many dirty pages) if segments without a
breakpoint are greater than 0.25% (i.e. 3 out of 10).
If all 10 segments are filled, then it will be expected (wait) for the first of
the segment
Set the maximum to 50% of the estimated value. If it is possible to use 60 GB
for the archive, set it to 30 GB.
