Redundancy and high availability

A gap left by an application-level failover can be patched afterwards. History import reads the values from the automation system's own OPC UA history store. The read is gap-based: it fetches only the missing periods and skips those already imported, so the same data is never duplicated. This requires that the automation system itself retains history — DataPortia cannot read values that are not stored anywhere. Configuring the import is described on the OPC UA data acquisition page.

Redundant server pair

Two OPC UA server addresses behind the same connection. If the primary does not respond, the connection moves to the other one without any user action.

Streaming replication

PostgreSQL's own method, in which the transaction log is shipped as a continuous stream to a second database server.

Active-passive

Only one DataPortia server acquires data at a time. The standby server shows the user interface normally, but its OPC UA acquisition and alarm subscriptions are switched off until it takes over.

DPFC

DataPortia Failover Controller. Atorcom's own separate program that monitors the PostgreSQL pair and handles the failover automatically — on Windows as well.

This level protects against a fault at the automation end: a crashed OPC UA server, a replaced process station or a broken network route. It does not protect against a fault in DataPortia itself — that needs the application-level pair. A redundant server pair requires that the automation system really does have a second OPC UA server: DataPortia does not create one, it uses what already exists. Configuring connections is described on the OPC UA data acquisition page.

The database level is established PostgreSQL technology, not a product-specific arrangement. That is a good thing: the cluster is managed with familiar tools, and a database specialist maintains it without separate training. The flip side is that the failover logic belongs to the database side — DataPortia works with it, but does not replace it.

Size the replication link according to the write volume: throughput is 2 000+ values per second, that is at most 172 million rows per day. Compression and retention periods are covered on the OPC UA data acquisition page; what passes through replication is in any case the fresh, uncompressed write stream.

DPFC runs as a separate process, not inside DataPortia. The reason is simple: when the primary database is down, DataPortia itself is either down or on its way down — the component whose job is to notice that cannot live inside the failing program.

The recommended configuration is three DPFC processes: one on each database node and one on a separate witness node that decides which node is primary. A light machine is enough for the witness node. If the witness node is down, automatic failover does not happen — the databases themselves keep running normally and the failover can be done by hand. The same limitation applies to pg_auto_failover's own monitor.

The same mechanism serves planned maintenance: the active server can be shut down and acquisition moves to the standby machine, so operating system updates and restarts no longer interrupt acquisition for hours. The failover time applies to the application level only — the database failover time depends on the cluster's own configuration.

A failover initialises connections the same way a normal start-up does: only those connections with Connect on start-up enabled are established automatically on the standby node. On production connections this setting has to be enabled, otherwise high availability does not work.

Alarms and events are stored with the automation server's original timestamp at millisecond precision, so material collected after a failover lands in the right place on the timeline and the moment of failover does not distort the order of events. More on the subject on the alarms and events page.

The number of servers is above all a question of what an outage costs. If the time series is part of regulatory reporting or invoicing, a gap is more expensive than a second machine. If the data drives maintenance and monthly monitoring, one server and careful backups are the right sizing. I go through the configuration at commissioning, so you do not have to decide the number of servers on your own.

If the environment already has PostgreSQL expertise or a ready-made cluster, DataPortia settles on top of it. If it does not, count in the maintenance workload as well — a two-server configuration is permanently more to manage than a single one.

No. The functions are in the same software, and I go through the configuration at commissioning.

Redundancy is a matter of configuration, so it can also be built on top of an existing installation. In practice it means a new server and rethinking the database level, so tell me about the plan sooner rather than later.

Yes. The database level is based on PostgreSQL's own streaming replication, so pg_auto_failover and Patroni both work. They only run on Linux, however. In a Windows environment the automatic failover is done with DataPortia's own DPFC controller — the alternative is scripted replication and a promote command given by hand.

Not in a database outage: alarm and event subscriptions buffer 50 000 events in memory by default and flush the buffer once the connection returns. If the application server crashes, events occurring during the failover are not collected. Collected alarms keep the automation server's original millisecond timestamp. DataPortia is a reporting system: the primary handling of alarms belongs to the automation system, not to reporting software.

Three items: extra hardware, configuration work and licences. Redundancy at the application level requires a separate HA add-on licence, licensed per installation — one licence covers the whole pair. On top of that the base licence is tied to the hardware, so each server needs its own base licence — or you use a floating licence, which is designed for exactly this. Tell me about your environment and I will work out the total.

Partly. The trial is 30 days with no commitment, but the HA add-on is not included in the trial period — the redundancy switch cannot be turned on in the trial version. Data acquisition, reporting and everything else can be tested normally, and I go through the high availability configuration with you separately.