Overview
When a Bor full node is running for a long time, the size of the data increases over time. Apart from the chain data, there is also bloat due to some temporal data. Hence, it is common to see a new, fully synced node consuming much lesser space than a node that has been running for a year, for example. Pruning is a feature that can be used to clear the bloat and bring back the size of an already running node to the original size of the chain. It was introduced in Geth 1.10.x and is available on Bor version 0.2.5 onwards.
Observations
We have tested pruning successfully on many of our nodes and we have seen a good reduction in size.
- It takes roughly 6-8 hours to prune the Bor database. Note that pruning can be started only when Bor is not running.
- Some High-Level Stats:
- Bor data size before pruning: Between 300 - 700GiB (Depending on when the node was running)
- Bor data size after pruning: 200 - 220 GiB
- If the archive node is pruned then it will lose all its archive data and will become a normal full node. So, do not run pruning on archive nodes.
Instructions for Pruning
If you are running a bor node and want to reduce the data size, follow the steps listed below.
Prerequisites
- The volume Bor stores its database on has at least 50 GiB of free space
- Bor v0.2.5+
- Bor is fully synced
- Bor has finished creating a snapshot, and this snapshot is 128 blocks old or older. You can tell it is done creating the snapshot when it is no longer showing “generating snapshot” messages in logs. Bor generates a snapshot by default, right after it is done syncing.
-
tmuxor similar installed:sudo apt install tmux. This intro is useful for navigating tmux.
Caveats
While we have tested pruning successfully on many of our internal nodes, there is a risk associated with it. The two failure modes we have seen already are:
- There is 50 GiB or less of free disk space
- The pruning process is interrupted partway through
- Restating the point that pruning is not for archive nodes
Steps
This process usually takes about 6-8 hrs to complete. So there will be some downtime for bor on your node.
For validators, if you’re planning to go ahead with pruning on your:
- sentry/full node - please let us know in advance so that we can help you with a different static node/peer your validator node can connect to.
- validator node - you can switch your Bor RPC URL to an external RPC URL so that you continue to sign checkpoints. You can later switch it back to the old value. Here is the list of external RPCs available for Bor: https://docs.matic.network/docs/develop/network-details/network/ You can use any one of them until pruning is complete.
Below are the steps for pruning:
- Check your bor data size before pruning
du -sh ~/.bor/data - Stop bor
sudo service bor stop - Start tmux to ensure that even if your ssh connection is reset, the process is running on the remote machine
tmux - Start pruning
bor —datadir /my/data/dir/ snapshot prune-state
The default--datadiris~/.bor/data - Once pruning is completed, you will see success logs and details, Then start bor again
sudo service bor start - Check your bor data size after pruning
du -sh ~/.bor/data
Details
Bor will prune in 3 stages: “Iterating state snapshot”, “Pruning state data”, and “Compacting database”. During the “Compacting database” stage, it may not output any log entries for an hour or so (mainstream SSD IOPS). Don’t restart it when this happens, let it run!
If you see messages about “generating snapshot” and an ETA during the prune, you don’t actually have a snapshot yet! Either the --datadir and/or USER aren’t right, or Bor just didn’t have enough time to complete the snapshot. In that case, stop the process, run Bor normally again, and observe its logs until the snapshot has been completed and is 128 blocks old.