Link between two Bravura Security Fabric servers goes offline

Attempted replication events, including sending a record of user logins from one server to another, will cause the sending server to detect the outage automatically. Other (still functioning) servers will start displaying a warning about replication problems and queuing updates until the unavailable server comes back on-line.

If the queue fills on replicated servers, these servers enter a DB COMMIT SUSPEND mode. At that time, the only available option is to remove the failed server from the functional servers’ replication configuration.

Each server continues to function, and queues updates to its peers until the link comes back up. Functionality is suspended if a configured retry-value has been reached, or if the queue fills.

The link between two Bravura Security Fabric servers becomes non-functional. This may be due to a bad NIC, network cable, network switch, router, WAN link, or something else. The result is that the two servers cannot communicate and consequently cannot replicate updates.

No data loss or – due to an unavoidable race condition – minimal data loss if updates on target systems were not yet committed to the database when the damaged server went offline

Restore connectivity quickly if possible, See Time available to fix problems .

Depending on when the failure occurs while the replicating data is being sent to the other servers, there may be some discrepancies between the nodes. If possible, check that the database backend is still up, and consolidate the databases.

If the network link cannot be fixed quickly, the affected Bravura Security Fabric server should be removed from the replication configuration on other Bravura Security Fabric servers promptly. Instructions for this are in Removing a node from replication . At a later date, the server should be returned to the replicating set using instructions from Synchronizing a new node with an existing set of Bravura Security Fabric replicas .