Upgrades & rollback
Pull a new release, run migrations, and roll back when one goes wrong
Upgrades are a git pull and a rebuild, and migrations run automatically on boot. This page covers the routine upgrade, the two cases that need a manual step, and how to roll back.
Upgrade to a new release
Pull and rebuild
git pull
docker compose build
docker compose up -dLet migrations run
Database migrations run automatically on backend startup. If one fails, run it by hand:
docker compose exec backend python manage.py migrateRe-run PeerDB init if the release notes say so
When a release changes which Postgres tables are mirrored, re-run init. The container’s entrypoint is already bash /setup.sh, so no arguments are needed:
docker compose run --rm peerdb-initNote
PeerDB init only rebuilds the tables it mirrors from Postgres. It does not restore the spans the fi-collector writes straight to ClickHouse, so it is not a recovery path for lost ClickHouse data. For that, restore from a ClickHouse backup.
Roll back a bad release
Roll back to the previous commit and rebuild:
git log --oneline -5
git checkout <previous-hash>
docker compose build && docker compose up -dWarning
Checking out older code does not undo a migration that already ran. If a release applied a migration you need to reverse, roll it back before you switch code, or restore Postgres from a backup.
Dive deeper
Questions & Discussion