Redundancy Settings

All redundancy settings are configured in the Ignition configuration gateway under Configuration>Redundancy. Most settings are used by both the master and backup nodes, with their individual settings broken out into separate categories.

It is important to know that while the full system configuration is shared between nodes, redundancy settings are not shared between nodes. Therefore, it is perfectly acceptable to have different values for the same settings on the two nodes. For example, it is possible to have a different Standby Activity Level on both nodes, and, of course, the network settings will often be different.

•	Independent - Redundancy is not enabled and this Ignition system runs as an independent node.

•	Master - This is the master node, who listens for a connection from the backup node, and is in charge of managing system synchronization.

•	Backup - This is the backup node, who will connect to the master and receive system updates.

•	Cold - perform minimal activities, do not connect to devices, etc. Purpose: minimize the load on the network and on devices.

•	Warm - Connect to devices, subscribe to tags and set up all executing objects. Purpose: minimize fail-over time.

The time, in milliseconds, before the opposite node is determined to be unavailable and this node takes over.

The time, in milliseconds, to wait on initial startup for a connection to be established before making a decision on the node's activity level. This is used to prevent unnecessary switch over caused by a node starting as active, only to connect and find that the other node is active, resulting in one of the nodes being de-activated. It is important to note that this setting can interfere with the Master Recovery Mode- if the master is active, it will always request the backup to de-activate. If this setting is low, or 0, the master will always become active before connecting to the backup, and thus "manual recovery" will not be possible.

For the master, the port to listen on. For the backup, the port to connect to on the master.

If true, the system will automatically select which network interface to use on the machine. If false, the system will bind itself to the interface of the specified address.

When clients are launched, they are provided with a list of addresses that they may connect to. If this option is true, the list will be generated automatically. If false, they will be provided with the list specified.

The list of addresses to give to the clients if auto-detect is turned off. These are the addresses that the clients will attempt to connect to, so the HTTP and HTTPS ports must match the configuration of the system in the Gateway Control Utility.

•	Automatic - The master automatically takes back responsibility, and becomes active. The backup node goes to standby.

•	Manual - The backup node is allowed to stay active. The master will become active if the backup node fails, or if the user requests a switchover from the gateway configuration page.

How many "runtime status updates" can be queued up in memory before the system stops tracking them and forces a full refresh. These updates represent information that the other node should have in order to have the same running state as the master when it's forced to take over. This is most often the values of static tags and the current alert state. Given that the update buffer is only used once the nodes are connected, the default value is usually fine, and only needs to be increased on systems that may have many alerts that change together, or many static tag writes.

•	Full - The system operates normally, and data is stored to the database.

•

Partial - The system caches all historical data until it can verify the time period that the master was actually down. This prevents the storage of duplicate data in the case that only the communication between the master and backup went down, resulting in a situation where both nodes ran as active for a period of time.