Gateway High Availability

Resolving The Problem

There is no peer-to-peer functionality available to have a hot standby gateway for high availability. Instead, having a cold standby gateway which is started only when the primary gateway is down is typically implemented. There would be a brief period between when the Primary gateway is down and the Secondary is not yet started when events are not sent. If you use the AFTER IDUC DO method to flag which events are sent by the gateway, any events not sent could be re-updated manually or through a trigger to send the events to the secondary gateway. This configuration is not officially supported.

For example, if there is a field SentByGateway which is set to 1 when the gateway reads the event (AFTER IDUC DO 'update alerts.status set SentByGateway=1'). The trigger can query the Object Server for events where SentByGateway is still 0 and the StateChange is older than 5 minutes to find the events not sent. For those events, any update can be ran, such as "update alerts.status set SentByGateway=0 where SentByGateway=0 and StateChange < (getdate()-300)". The update isn't really changing the event, but will cause the StateChange field to be updated and the event will be resent to the gateway when it is connected.

There is an example configuration and scripts which describe the cold standby method for the JDBC gateway. The document is specific to the JDBC gateway, and this is the only supported high availability configuration for the JDBC gateway. The high availability documentation for the JDBC
gateway is available on developerworks

JDBC gateway high availability