Dual Storage Operations#

Since version 1.0 (pro edition), the series values can live on either of two storage backends:

  • pg - the historical PostgreSQL backend

  • fs1 - a high-performance filesystem backend

Each series individually carries its backend. The catalog and the metadata always stay in PostgreSQL, whatever the backend of the values. Both kinds coexist transparently in the same instance: the API, the formulas, the supervision and the web interface behave identically.

Configuration#

The [storage] section of tshistory.cfg provides the fs1 root directory (mandatory) and optionally the default backend for newly created series. See the configuration reference.

Moving series between backends#

The change-backend command schedules the migration of every series and group of a namespace towards a target backend:

tsh change-backend <instancename> --target fs1

The migration runs through the task queue, series by series, in a chunk-streamed fashion: the platform keeps running while it proceeds, and several workers can consume the queue concurrently. Series already migrated (or already queued) are skipped, so the command can be re-run safely to resume an interrupted campaign.

A pending campaign can be cancelled - series not yet picked by a worker stay on their current backend:

tsh cancel-backend-change <instancename>

A cancelled campaign can be relaunched later with tsh resume-backend-change <instancename>.

Operational notes#

  • The fs1 directory belongs in your backup perimeter, next to the database dumps.

  • fs1 files are append-only; revisions are fsynced before being committed.

  • The --target option also accepts pg, so a campaign can be reversed.