NGA redundancy

CAUTION: This scenario is only available for InfluxDB® and PostgreSQL®

Redundancy with duplicated Database Instances managed by NGA:

In case of databases which are not redundancy-capable, NextGen Archiver must take care of the main redundancy use cases:

  • Keep passive DB in sync with the active one
  • Switchover between redundant partners
  • DB Sync after restart of a passive system
  • Including database / connection state in overall “system health”
Figure 1. NGA redundancy architecture

The basic idea to perform this is to use two identical backends on each redundant node, one connected to the local database, the other one to the database on the redundant partner. The active server is writing to both backends, the passive server just buffers the data blocks until they have been successfully written to the databases by the active backend, then this data is discarded.

In case of a redundant system, the NGA frontend sends all data additionally to the backend writing to the other server (“Backend 2” in the picture above). After a switchover, the formerly passive server starts to write the existing buffers (which have not yet been committed by the formerly active server) into the databases (local and remote).

If the other server (or at least the database) is down or unreachable, the backend writing to this host will buffer the data. To cover a longer time range in a redundant environment the buffering method must be set accordingly (buffer to disk) – see Configuration - Frontend.

After the restart of the passive server / database, the backend of the active server writing into the passive database will automatically detect the availability of the database and start to write the buffered data (recovery). The passive system will delete any locally stored buffers automatically if data has been written by the active server.

All read requests for historical values / alerts (dpGetPeriod, dpGetAsynch, alertGetPeriod, dpQuery) from user interfaces will automatically be routed to the active system by the Event Manager. Control managers must be started by using the command line parameter "-connectToRedundantHosts" to be automatically routed to the active host. This is standard WinCC OA redundancy behavior.

Figure 2. WinCC OA System Overview panel for a redundant NGA project

The NextGen Archiver is also shown on WinCC OA’s System Overview panel.

When a project is generated which is using NGA, the standard backend (PostgreSQL®) is displayed for both redundant nodes and the error state calculation includes the NGA manager (instead of Value Archive or RDB manager), The weight is calculated based on the backend connection to the database (bad = no connection to database).

Note: Split mode is not available for redundant NGA projects! Split mode is not disabled in the panel. Therefore, do not use it in a redundant project.

For additional notes on security of PostgreSQL® databases, see chapter PostgreSQL® Notes.