|
| 1 | +# Pruning State |
| 2 | + |
| 3 | +To reduce hardware requirements and improve the overall latency of the node, |
| 4 | +operators are encouraged to prune their state (unless they are archivers or |
| 5 | +historical nodes). |
| 6 | + |
| 7 | +As will be explained in the following sections, pruning should be configured from |
| 8 | +the start, i.e. late changes to the pruning configuration may not be optimal for |
| 9 | +the node's health. |
| 10 | + |
| 11 | +## Consensus Pruning |
| 12 | + |
| 13 | +To configure pruning of the consensus data amend your node's configuration with: |
| 14 | + |
| 15 | +```yaml |
| 16 | +# ... sections not relevant are omitted ... |
| 17 | +consensus: |
| 18 | + # ... sections not relevant are omitted ... |
| 19 | + prune: |
| 20 | + strategy: "keep_n" |
| 21 | + num_kept: <n> |
| 22 | +``` |
| 23 | +
|
| 24 | +where `<n>` is the number of blocks and state versions that will be kept. |
| 25 | + |
| 26 | +### Suggested Pruning Configuration |
| 27 | + |
| 28 | +For normal node operation, the minimum requirements is `n=250_000`. However, |
| 29 | +it is recommended to set it to `n=400_000`. Assuming blocks are produced every 6 |
| 30 | +seconds, the latter corresponds to preserving 1 month of the consensus data. |
| 31 | + |
| 32 | +Operators that are not resouce-restrained and want to contribute to the overall |
| 33 | +network health are encouraged to set `n=5_000_000` (approximately 1 year of data). |
| 34 | + |
| 35 | +### Late Pruning |
| 36 | + |
| 37 | +Due to the [LSM Tree][] design of the underlying databases, enabling pruning after |
| 38 | +your node has been runing for a while, or possibly changing configuration to retain |
| 39 | +less data, may may not work as expected. |
| 40 | + |
| 41 | +To change pruning configuration operators must follow this steps: |
| 42 | +1. Gracefuly shutdown the node (validators should take [special care][graceful shutdown]). |
| 43 | +2. Configure pruning as described in [Consensus Pruning](#consensus-pruning). |
| 44 | +3. Run offline pruning (TODO insert link). |
| 45 | +4. Run the [compaction command][]. |
| 46 | +5. Start the node again. |
| 47 | + |
| 48 | +[LSM tree]: https://en.wikipedia.org/wiki/Log-structured_merge-tree |
| 49 | +[graceful shutdown]: ../maintenance/shutting-down-a-node.md |
| 50 | +[compaction command]: https://github.com/oasisprotocol/oasis-core/blob/master/docs/oasis-node/cli.md#compact-experimental |
| 51 | + |
| 52 | +## Paratime Pruning |
| 53 | + |
| 54 | + |
| 55 | +To configure pruning of the paratime data ammend your node's configuration with: |
| 56 | + |
| 57 | +```yaml |
| 58 | +# ... sections not relevant are omitted ... |
| 59 | +runtime: |
| 60 | + # ... sections not relevant are omitted ... |
| 61 | + prune: |
| 62 | + strategy: "keep_last" |
| 63 | + num_kept: <n> |
| 64 | +``` |
| 65 | + |
| 66 | +where `<n>` is the number of paratime's state versions that will be kept. |
| 67 | + |
| 68 | +### Suggested Pruning Configuration |
| 69 | + |
| 70 | +Paratime state is much larger than the consensus state. As a consequence, as the |
| 71 | +number of versions in the state database grows, pruning becomes slower and slower. |
| 72 | + For this reason **paratime state pruning must be configured |
| 73 | +from the start or not configured at all**. |
| 74 | + |
| 75 | +To configure pruning it is recommended to set `n=250_000`. The maximum value is |
| 76 | +`n=400_000`. If you need to preserve more data (e.g. nodes serving historical |
| 77 | +state) you will have to keep the entire state from the genesis. |
0 commit comments