Ignition Database - Redundancy Options

Hi all,

I am interested in configuring an Ignition database using for storing tag history for high availability. I read the related article in the user guide (see here), but felt like it was somewhat light on what type of architectures are supported. I am specifically curious: can an Ignition SQL database be made redundant using Windows Server Failover Clustering (WSFC), or does the redundancy have to be facilitated via one of the SQL high availability options (e.g., clustering, mirroring, transactional replication, or AlwaysOn Availability Groups)?

Also, how are these architectures facilitated in practice? For example, if I set up a WSFC, do I have to set up an Ignition tag history splitter, as detailed here?

Appreciate any insights people can share!

P.S.: I found a somewhat related article (see here) on the forum, but a) it concerns PostgreSQL and b) it’s four years old at this point.

Ignition itself doesn’t do database redundancy. It can connect to a master-master pair with the failover option in the datasource setup, but it doesn’t otherwise participate in redundancy operations.

True high-availability database clusters generally expose one public address/host name that is then proxied or balanced or dynamically reconfigured to the underlying database instances. Totally outside of Ignition’s scope.

FWIW, I’ve never had to set one up. My clients just pick their favorite commercial solution.

3 Likes