Skip to content

Upgrade

Upgrading Catena is upgrading packages; the configuration, the secrets and the database survive it with no operator involvement.

One machine

apt update && apt install catena

The catena package upgrades the streaming server to exactly its version. The running service is left alone — the process keeps running on the previous binary, and a manual restart moves it to the new one:

systemctl restart catena

Worth knowing:

  • You choose the moment of interruption: the machine's channels are interrupted only for the process restart — the warm start brings them up right after. Restart in a window convenient for the broadcast.
  • The secrets are not rotated: /etc/catena/secrets.env survives any upgrade, the passwords do not change.
  • Central applies the database schema itself on start — there is no separate migration step.

On streamers, the catena-streamer package upgrades the same way; the restart is the same command.

The cluster

Upgrade the machines one at a time. That is safe by construction:

  • the wire protocol only grows by addition — the sides ignore unknown fields, and central and streamers of neighboring versions work together;
  • the database schema is compatible within a window of two versions back — N−1 and N−2 code runs against a newer schema.

Stay inside that window: do not let the version spread within the cluster exceed two. There is no mandated "central first, streamers second" order — the guarantees are symmetric; in practice it is convenient to start with central, so the console shows the new version's capabilities right away.

Rollback

A newer database schema under older code is the norm: rolling the binary back one or two versions does not require rolling back the database. Install the previous package version — and that is it. The database itself is only rolled back together with a restore from a dump, and that is no longer a version rollback but disaster recovery.