281017ae90
## Description removes the dependency of tendermint/utils/log from countless locations. This is in effort of reducing Tendermint's lib usage in the sdk this is nonbreaking as the interface is the same. To eliminate tm/utils/log in the sdk we need a few more things. Once we have fully removed the tendermint logger, I would propose we break the interface and define our own for our use case, when we pass the logger to tendermint in the node.New() function we can wrap our logger for its use case --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) |
||
|---|---|---|
| .. | ||
| types | ||
| export_test.go | ||
| manager_test.go | ||
| manager.go | ||
| README.md | ||
Pruning
Overview
Pruning is the mechanism for deleting old application heights from the disk. Depending on the use case, nodes may require different pruning strategies. For example, archive nodes must keep all the states and prune nothing. On the other hand, a regular validator node may want to only keep 100 latest heights for performance reasons.
Strategies
The strategies are configured in app.toml, with the format pruning = "<strategy>" where the options are:
default: only the last 362,880 states(approximately 3.5 weeks worth of state) are kept; pruning at 10 block intervalsnothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)everything: 2 latest states will be kept; pruning at 10 block intervals.custom: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
If no strategy is given to the BaseApp, nothing is selected. However, we perform validation on the CLI layer to require these to be always set in the config file.
Custom Pruning
These are applied if and only if the pruning strategy is custom:
pruning-keep-recent: N means to keep all of the last N statespruning-interval: N means to delete old states from disk every Nth block.
Relationship to State Sync Snapshots
Snapshot settings are optional. However, if set, they have an effect on how pruning is done by
persisting the heights that are multiples of state-sync.snapshot-interval until after the snapshot is complete. See the "Relationship to Pruning" section in snapshots/README.md for more details.