-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: keep 9W blocks in ancient db when prune block #2481
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
cmd/utils/flags.go
Outdated
@@ -1082,6 +1082,7 @@ Please note that --` + MetricsHTTPFlag.Name + ` must be set to start the server. | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use params.FullImmutabilityThreshold
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
9561de1
to
8c11ccb
Compare
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: