v2024.02 Upgrade Notes

Core Team

Mainnet full node and lite server owners

Please update your mytonctrl and validator node.

Target versions:

mytonctrl

b9d5937

validator

692211f

1. Check your OS version

Compatible versions:

- Ubuntu 20.04, 22.04

- Debian 11

2. Make sure what your mytonctrl from an official repository

$ cd /usr/src/mytonctrl && git remote -v

origin https://github.com/ton-blockchain/mytonctrl.git (fetch)

origin https://github.com/ton-blockchain/mytonctrl.git (push)

In case of errors add git safe directories:

git config --global --add safe.directory /usr/src/mytonctrl

git config --global --add safe.directory /usr/src/ton

3. Check branches

In mytonctrl run `status`, under "Local validator status" find current versions:

Version mytonctrl: xxxxxx (master)

Version validator: yyyyyy (master)

Both must be on "master" branch

4. Update node

Run commands via mytonctrl*:

- `update`

- `upgrade`

* if you don't use mytonctrl please manually rebuild code from master branch of https://github.com/ton-blockchain/ton

5. Re-check versions as in #3 and compare with target versions

NB: do not update all nodes at the same time; best practice is to make updates in small batches or one by one

5. DB Grooming

After successful upgrade, we recommend to execute DB grooming:

To do it:

stop validator

systemctl stop validator

verify that validator not running

systemctl status validator

Perform database cleanup (note, you don't need to manually delete temp.archives anymore)

find /var/ton-work/db -name 'LOG.old*' -exec rm {} \;

Start validator service

systemctl start validator

Check that you machine(s) meet system requirements outlined in https://t.me/tonstatus/85 and have at least 300 Gb of free disk space, otherwise schedule migration to the server that meets requirements.

6. Liteserver configuration

For faster starts node doesn't automatically open all files.

Moreover flag --max-archive-fd determines maximum number of files that can be opened. If node need to open more files it will first close least recently used to not get above limit. By default, this limit is not set, however there are usually limits on OS level that need to be considered.

It need to be noted for Liteserver operators, that when liteserver get request data for which is in not yet opened file, it responds with error and start to open file in background. That may lead to unwanted heating up period prior LS starts to respond with appropriate error rate. To mitigate this behavior the flag --archive-preload-period can be used. It tells node for which recent period of time to open file on the start. So, if you expect that you liteserver will generally asked for recent data set this parameter to 7776000 (three months) for faster stars. In contrast if you work with archival node and expect many historic queries, set this to some high number, for instance 630000000, to force node to open all available files and be ready to answer all queries (however startup will require more time).