Dev data consistency #785
Dev data consistency #785
Conversation
|
Looks like you've updated the documentation! Check out your changes at https://neo4j-docs-operations-785.surge.sh |
renetapopova
force-pushed
the
dev-data-consistency
branch
from
1f4fc91 to
53cc93b
Compare
renetapopova
force-pushed
the
dev-data-consistency
branch
from
acd93dd to
4983600
Compare
modules/ROOT/pages/database-internals/transaction-management.adoc
Outdated
Show resolved
Hide resolved
|
Huge thanks for the review, @mnssn! Apologies for the confusion with this leftover |
| |VOLUMETRIC | ||
| |label:enterprise[Enterprise Edition] | ||
| This policy checks every 10 seconds if there is enough volume of logs available for pruning and, if so, it triggers a checkpoint and subsequently, it prunes the logs. | ||
| By default, the volume is set to 250MiB, but it can be configured using the settings xref:configuration/configuration-settings.adoc#config_db.tx_log.rotation.retention_policy[`db.tx_log.rotation.retention_policy`] and xref:configuration/configuration-settings.adoc#config_db.tx_log.rotation.size[`db.tx_log.rotation.size`]. |
There was a problem hiding this comment.
@mnssn, Is this sentence technically true?
There was a problem hiding this comment.
It is true that db.tx_log.rotation.retention_policy is used to configure volumetric.
For db.tx_log.rotation.size the interplay is more subtle. This setting specifies how much space a single file of the transaction log may roughly occupy. This influences how much space can be reclaimed by all strategies by virtue of the following.
To reclaim a given file, the newest checkpoint for the transaction log must exist in another file. So if you have a huge transaction log, then it is likely that your latest checkpoint is in the same file, making it impossible to reclaim said file.
No description provided.