BooleX.ai DOCS Book a demo
Documentation

Get started

Set up

Get answers

Quick reference

Manual

IT documentation

Guides

Reference

Docs / IT documentation

High availability

A standby edge PC that mirrors the store and takes over within 5 minutes.

The high-availability option pairs two edge PCs. The primary collects plant data and serves the Web UI; the standby keeps a streaming copy of the primary's store and takes over when the primary fails. It is an option for data centres and utilities; one edge PC remains the default.

TargetHow
Replication lagunder 60 sPostgres streaming replication of the whole store. A platform alarm is raised at 60 s, or when nothing streams
Takeoverwithin 5 minutesThe standby reads the primary's status every 10 s; after 120 s without an answer it promotes its store and starts the Web UI and the collectors (about 2.5 minutes)
Data lost on takeoverat most the replication lagTypically under a second

Both PCs stay read-only to the plant. Only the active PC reads the PLCs.

Network

A dedicated link between the two PCs (a cable, or a VLAN inside the diagnostics zone) carries replication (F11, 5432/TCP, standby to primary, role replicator from the standby's address only) and the agents' status (F12, 8099/TCP, both ways, GET /state only). Both PCs need the same flows to the plant and site services, since either may collect.

Set-up

On both PCs install the edge stack as usual, then:

  1. Start the store with the HA override, with BOOLE_HA_ADDRESS set to the PC's address on the HA link: docker compose -f deploy/compose.yaml -f deploy/compose.standby.yaml up -d.
  2. On the primary: deploy/standby/init-primary.sh <standby HA address>, and copy deploy/secrets/db_replication to the standby.
  3. On the standby: deploy/standby/init-standby.sh <primary HA address>. This replaces the standby's store with a base backup of the primary's and starts streaming. Do not start ingest or assistant on the standby.
  4. On both: install deploy/standby/boolex-standby.service (which runs python -m settings.standby), write deploy/standby/standby.env from standby.env.example, and enable the service.

Check: the primary shows no platform alarm; on the standby, SELECT * FROM pg_stat_wal_receiver shows streaming.

When the primary fails, and comes back

The standby takes over by itself with a higher epoch. Users reconnect to its address; give both PCs a shared DNS name or a site load balancer so they need not change addresses.

The old primary stays passive when it comes back: it sees the standby active with a higher epoch and does not collect, so the PLCs are not read twice. To make it the new standby, stop its ingest and assistant, run init-primary.sh on the active PC and init-standby.sh on the old primary, set BOOLE_HA_ROLE=standby in its standby.env, delete /var/lib/boolex/standby.json and restart its agent.

Limits

  • Two nodes, no witness. If only the HA link breaks, both PCs become active and each raises a platform alarm that its peer is not answering. Stop the services on the PC with the lower epoch (in /var/lib/boolex/standby.json) and rejoin it as above.
  • Replication is asynchronous. A write committed just before the primary fails may not reach the standby.