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.
When working with various database architectures, there are a few settings in various parts of the system that are important.
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.