Tags

If using the default internal provider, Tags only rely on the database for Tags which execute queries. These Tags will error out if the database is unavailable, but the status and control functionality of the system will function on the whole. If using an external provider, which is housed in the database, the Tags will no longer function. Therefore it's much more important to have a read-capable database connection available when using external tags.

History - Tags and Other

All history in Ignition goes through the store-and-forward system, meaning that it will be cached until the database is available. However, while the data is cached, it will be unavailable to view or analyze on the clients. Therefore, when looking at how the database should be set up, it is necessary to determine how crucial rapid-availability of the data is.

Alarming

The alarm status system does not reside in the database, so it will continue to function if the connection is down. Alarm Journal information will go through the store-and-forward system as history data.

Project screens

Almost all projects use database access for providing information on screens. These queries will error out as long as the database is unavailable. Screens that only use Tags (in an internal provider) will continue to function, so it would be beneficial to make a distinction between status screens and history screens, if a failover database is not used.

Single Shared Server

A single database server is used. Any Ignition gateways will use it, so it is expected to be available even when one of the nodes is not. For that reason, it almost always resides externally, on a separate server machine. This arrangement is the easiest to use with Ignition. A single database connection configured on the master will be replicated to the backup, and both nodes will use the connection as necessary.

Clustered/Replicated Database Servers

There is a wide variety of capabilities supported by the different brands of database servers. To obtain fault-tolerance on the database front, it is usually necessary to have some sort of cluster/replication system in place. However, it can be very import to examine how Ignition is using the databases, and what capabilities the clustering solution provides.

For example, in many replication scenarios, the master database copies data to the backup. The backup can be used for read purposes, but new data inserted will not be replicated back to the master. Therefore, it is possible to have a failover connection to the backup database, so that clients will continue to receive data, but it would be necessary to run in partial history mode, so that the historical data was cached and inserted only to the master database. The failover connection would be set to standard mode, so the primary connection would be used when possible.

In a more complete cluster environment, where writes to either node would be replicated, a sticky failover connection could be used with full history mode.

Database connection settings - Failover Datasource

Any database connection can have a failover datasource. If the main connection is unavailable, any queries executed on it will pass through to the secondary connection. In this way, a secondary database can be used when the first is not available, and the system will continue to function. It is important to note that everything passed through to the failover will function normally- no special considerations will be made. For example, the system won't cache data for the primary connection, it will forward it to the secondary. In cases where you want to allow reading from the secondary database, but not writing, you can set up another connection directly to the first database, with no failover, and set all of your write operations to use that.

Clustering settings - History Mode

The history mode dictates how history will be treated when the node is not active. If partial, the data will be cached, and only forwarded when the master node is available. This mode can be used to prevent data from being inserted into a backup database in some cases. This setting can be found on the Redundancy page under the Configure section of the gateway.

Similar Topics ...

• Redundant Licensing