fix: keep 9W blocks in ancient db when prune block#2481
fix: keep 9W blocks in ancient db when prune block#2481zzzckck merged 5 commits intobnb-chain:developfrom
Conversation
cmd/utils/flags.go
Outdated
| Name: "block-amount-reserved", | ||
| Usage: "Sets the expected remained amount of blocks for offline block prune", | ||
| Category: flags.BlockHistoryCategory, | ||
| Value: 90000, |
There was a problem hiding this comment.
Use params.FullImmutabilityThreshold.
9561de1 to
8c11ccb
Compare
|
LGTM |
There was a problem hiding this comment.
LGTM.
1.This PR revert the upstream commit: https://github.com/ethereum/go-ethereum/pull/28683/files?diff=split&w=0
Actually, it is not that necessary, we can keep this commit. But it is ok to revert as well, we can get it back during our next code merge.
2.This PR will prevent use from pruning block of the most recent FullImmutabilityThreshold (9w) blocks.
3.But due to the multi-DB feature, the freeze logic is different now, it will only keep quite a few blocks in mainDB, so the these block access will only be kept in memory.
Simply describe it as bellow:
a.MultiDB:
--ancientDB: 0 -> finalizeHeight-1
--mainDB: finalizeHeight -> head
b.No MultiDB or MultiDB with --pruneancientdb:
--ancientDB: 0 -> head-9w
--mainDB: head-9w -> head
Description
After introducing the feature to use the finalized block as the chain freeze indicator for the multiDatabase feature, the kv database only contains a few dozen blocks. Performing prune block operations and then force-killing the process can lead to the blockchain rewinding to a non-existent block. To address this issue, the prune block will by default retain 90,000 blocks in the ancient database.
Rationale
Other Changes:
These changes ensure that the blockchain does not rewind to a non-existent block during force-kill scenarios and provide better operational logging and bug fixes for prune block executions.
Example
add an example CLI or API response...
Changes
Notable changes: