This document describes the steps to upgrade a node running go-opera v1.1.1 to the go-opera v1.1.3-rc.5
- Make sure to stop the go-opera node first and that the node is not restarted before processing the next steps
pkill opera
cd go-opera/
git checkout release/1.1.3-rc.5
make
- Confirm your go-opera version
./build/opera version
Go-Opera
Version: 1.1.3-rc.5
There's two migration options for upgrading to 1.1.3-rc.5:
- Preserving legacy DBs layout:
--db.migration.mode reformat --db.preset legacy-ldb
. This option is instant but involves no performance improvement for blocks/events processing. - Rebuilding DBs according to a new layout:
--db.migration.mode rebuild --db.preset X
, where X is a selected DBs layout. Migration will take a lot of time - for an NVMe SSD drive, the number of hours would be roughlydatadir size in GB
divided by 100GB/hour
. If the remaining disk space is insufficient to store a copy of largest DB in datadir/chaindata, then the migration will take up to 3 times longer, depending on available disk space.
Flags --db.migration.mode
and --db.preset
are mandatory only for first launch.
There are 2 options for the new --db.preset
flag:
ldb-1
- fastest LevelDB layout (default option).pbl-1
- fastest Pebble layout.
Pebble offers slightly better performance and smaller IO utilization on average, especially with extended cache.
We don't recommend using pbl-1
or legacy-pbl
layouts for validators or any other mission-critical nodes.
To migrate from an existing opera version (1.1.1-rc.2), please use:
--db.migration.mode reformat --db.preset legacy-ldb
This applies to all types of nodes (including API, rpc and validator nodes). Reformatting will finish almost instantly.
You can use: --db.preset ldb-1
You don't need --db.migration.mode
flag, if you don’t migrate an existing DB.
You can use either:
--db.preset ldb-1
(This flag will sync slightly faster, but may respond slower on multiple parallel API queries)--db.preset pbl-1
(This flag will sync longer, but have more stable API response time).
Follow Launching go-opera readonly node and substitute migration flags above.
Follow Launching go-opera validator node and substitute migration flags above.
Regarding cache size, you may check your node available memory size and consider changing the default Opera cache size to a bigger value based on that.
For example: --cache 16000
for a node with more than 16GB of RAM.
There is an imposed limit of 60% of the available RAM of your machine, if cache size is specified larger than that value.