About database replication
Data replication can be done in many ways, to be described in detail in the following sections.
Bravura Security does not recommend using natively replicated databases or cluster nodes on the backend, because it can result in:
Best case, in a shared schema, with the database engine moving too much data between data centers (including many cache and temporary tables needed only locally, about 40% of the database size).
In cases where the replicated database or cluster configuration solution used lock the product schema while processing native replication, it can lead to failed auto discoveries or even data corruption.
The highly recommended replication strategy, included by default in Bravura Security Fabric , is application-level database replication, which is transaction-based:
Only the data that needs to be replicated is copied over.
Any bulk changes are applied as stored procedures (they run fast on each database and only a few strings are sent over: the stored procedure name and its arguments).
The schema is never locked by replication itself, so it is available for changes without locking records or entire tables, resulting in faster performance.
How many databases to use:
One database node exposes the instance to failure with no possible historical data recovery.
Two database nodes in replication expose the instance to outages whenever database propagations from one node to another are required.
Three database nodes provide the most reliable architecture for instances which have a legal responsibility to Audit and a requirement for maximized application uptime.