Ignition redundancy: what actually fails over

Redundancy in Ignition is well documented and reliably repeatable to set up. The configuration replicates cleanly, which makes it tempting to assume everything else does too.

What the pair actually is

Ignition redundancy is a two-node arrangement: one master gateway and one backup. The master manages the configuration and replicates it to the backup, and when a backup connects it retrieves the updates, or downloads a full system backup if it has fallen too far behind.

By default the two nodes hold the same configuration state. From 8.3 that default can be varied deliberately: Backup Versions let an individual resource carry different settings on the backup node, which matters when the backup sits somewhere else on the network and something it connects to has a different address. A few areas are excluded from this, including gateway settings, because differences there would cause conflicts rather than solve them.

One exception looks like a fault the first time you meet it and is not. Redundancy settings themselves are not shared between nodes — Inductive Automation states that it is perfectly acceptable for the two nodes to have different values for the same settings.

Both nodes need licensing, and the backup generally needs the same modules as the master, on the reasoning that a failover is a poor moment to discover a missing capability. Inductive Automation does carve out non-critical modules: their example is Symbol Factory, which the backup does not need because the Designer only connects to the master.

The database is a separate decision

This is the assumption worth checking hardest, because redundancy is often bought as an availability answer and then quietly treated as a data-protection one.

The common arrangement is a single shared database server, with one connection configured on the master and replicated to the backup, used by whichever node is active. In that arrangement a redundant pair gives you a second gateway and not a second database, and the data already written is protected by that database’s own backups.

On 8.3 the shared-database assumption is worth testing before you rely on it. The Core Historian is an embedded time-series store, and the legacy Internal Historian is an embedded SQLite database; both write to the gateway’s own disk. With either of those, history is genuinely node-local rather than shared, which is a different answer to “what travels between nodes” than an external database gives you.

Database fault tolerance is available, but it is a separate piece of work rather than something redundancy provides. Inductive Automation documents clustered and replicated database servers for exactly this, and any database connection can carry a failover data source so a secondary database is used when the first is unavailable. The point is that you have to decide to do it: adding gateway redundancy does not add it for you.

Both of those act on an external database connection, so neither helps if history is node-local in an embedded historian. The documented equivalent there is the Historian Splitter, which writes tag history to two providers at once — Inductive Automation lists redundancy among its uses.

The distinction worth holding on to is between data in transit and data at rest. Data on its way to an external SQL historian is buffered by store and forward, within limits — we wrote about what that buffer does and does not cover separately. On 8.3 the Core Historian is an exception: it writes directly to disk with a write-ahead log and does not use store and forward at all. Data already in the database is protected by the database’s backups and by any replication you arranged. Failing over to the backup node addresses neither, because it answers a different question: the gateway host died, not the database is gone.

Module-local state is the module author’s problem

Configuration replication covers what the gateway owns as configuration. What happens to state a third-party module keeps for itself is less settled, and it is worth being precise about who guarantees what.

Inductive Automation’s SDK guidance tells module authors that anything stored in the internal database must reach the backup node, and that the PersistentRecord system handles this automatically, with other changes able to be duplicated through the redundancy manager. It also describes registering handlers to carry runtime state across the redundant network when a module cannot simply rebuild it on startup. So there are supported paths. What there is not, in the user manual, is a general platform guarantee about everything a module might keep outside them — which means the answer is specific to each module rather than something you can assume from the platform.

In our own case, each node generates its own gateway ID, so a key bound to the master will not validate on the backup. That is our observation about our own modules, not a documented property of Ignition. For Company News the second key is issued free with the primary purchase — send both gateway IDs with the order. For any other licensed module, including ours, the question to put to the vendor is simply: what happens to your licensing in a redundant pair, and who pays for the second node?

The test that tells you the truth

Configuration replication is easy to verify and easy to trust, which is why most people stop there. The useful exercise is a deliberate failover on a planned afternoon, with someone watching the things that are not configuration.

One setting to check before you start, or the test will mislead you: the backup history level. In partial mode the backup does not store history the same way the master does, so a failover can show history being cached rather than landing, which looks like a failure if you were not expecting it.

Does history keep landing, and does that match the history level you configured?
Do licensed modules run on the backup, or fall back to unlicensed behaviour?
Does anything that keeps state on the gateway filesystem behave differently on the other node?
When you fail back, does anything need reconciling by hand?

Every one of those has an answer you can find in an afternoon, and finding it on a Tuesday is considerably cheaper than finding it during the outage the pair was bought to survive.

Common questions

What is shared between redundant Ignition nodes?

By default the master manages the configuration and replicates it to the backup, so projects and gateway settings are shared and both nodes hold the same configuration state. From Ignition 8.3, Backup Versions allow individual resources to differ on the backup node. Redundancy settings themselves are not shared, and it is normal for the two nodes to have different values for those.

Does Ignition redundancy protect my database?

Not by itself. In the common single-shared-server arrangement a redundant pair provides a second gateway rather than a second database, and data already written is protected by that database’s own backup arrangements. Inductive Automation documents clustered and replicated database servers, and failover data sources on a connection, but those are separate decisions you have to make.

Do I need a licence on the backup node?

Yes. Both nodes require licensing, and the backup generally needs the same modules as the master. Inductive Automation notes an exception for non-critical modules, giving Symbol Factory as an example, since the Designer only connects to the master.

Do third-party modules need a separate key for the backup node?

It depends on the module, and Inductive Automation does not document a general guarantee about module-local state across a redundant pair. In our modules each node generates its own gateway ID, so a key bound to the master will not validate on the backup. For Company News the second key is issued free with the primary purchase.